Error objects in W3C APIs

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Feb 4 08:46:21 PST 2014


On Feb 4, 2014, at 6:28 AM, Boris Zbarsky wrote:

> On 2/4/14 4:27 AM, Jonas Sicking wrote:
>> The advantage of A is that it follows the pattern of current JS
>> errors. The disadvantage is that it clutters the global object with a
>> lot of error constructor functions which doesn't really provide any
>> value as far as I can tell.
> 
> Don't they allow easy creation of these new error types from script?
> 
> There is no nice way I can see, from script, to produce an instance of Error with .name set to something else.  You have to new Error() and then explicitly set .name on the resulting object or something.  So a typical pattern like:
> 
>  throw new FooError("xyz");
> 
> becomes:
> 
>  var err = new Error("xyz");
>  err.name = "FooError";
>  throw err;
> 
>> Such information is possible even using option B, but requires that
>> properties are added on the error object instances, rather than as a
>> getter on the prototype (which is the pattern used by other properties
>> on Error subclasses).
> 
> Adding the properties on the instances via the constructor is still nicer, as above...
> 
> I guess pages could basically define their own error constructors if they wanted to.
> 

We could consider respecifying Error.prototype.name such that:

class FooError extends Error{} 
console.log(new FooError("xyz").name); //outputs "FooError"


It would require changing Error.prototype.name from a data property to an accessor property that looks at the 'name' property of the this value's constructor.  Probably something like:

get name() {
     var name = this.construtor.name.
     return name? name : "Error";
}

Allen
     


More information about the es-discuss mailing list