Error objects: RangeError, TypeError, ValueError

John J Barton johnjbarton at
Tue Nov 22 20:36:27 PST 2011

On Tue, Nov 22, 2011 at 10:49 AM, Allen Wirfs-Brock
<allen at> wrote:
> On Nov 22, 2011, at 10:14 AM, Brendan Eich wrote:
>> On Nov 22, 2011, at 9:37 AM, Allen Wirfs-Brock wrote:
>> ...
>>> Unfortunately, as it now stands  you have to use the implementation dependent message property value to actually identify specific exceptions.
>> * is normatively specified for all the built-in Error constructors.
> Yes, but name doesn't discriminate the actual cause of the exception.

"actual cause of" can mean different things. I guess here you mean
"the particular failure path described in the standard for the
function that triggered".  The unique error path in the specification
could be given an unique name and that unique name could be encoded in
the type name or .name field or the toString(). I think this would be
attractive to implementers simply because it would give concrete
instructions for these cases. The unique names would be helpful for
devs, a search would lead to the standard spec if nothing else and can
be useful keys for docs.

I guess a |name| field and spec that says it should appear somewhere
in the toString() has the best chance for adoption. Typenames are more
overhead. Go with the simplest solution that can get the most info
into the Error object.

> There is no normative way to distinguish a RangeError generated by 1.0.toPrecision(40) from a RangeError generated by (new Array(1.2))

A great way distinguish these cases is to include the text of the
source that triggered the exception, eg "RangeError at (new
Array(1.2))". Unfortunately I don't think browsers will agree to
implement this.

>>> I wonder if for new exception occurrences (in our specs.) we should specify unique implementation independent name property values. To do so, we would have to develop a meaningful fine-grained naming scheme.
>> This would fit in just Error, as JJB just suggested.
> The difference is that instanceof can be used to detect RageError, TypeError, etc. instances

This has limited use because we can't magically cause all exceptions
to be correctly typed and because exceptions can jump across iframes
and the instanceof test only works within a single iframe.

(BTW we really need ChainedError in JS).


More information about the es-discuss mailing list