Error objects: RangeError, TypeError, ValueError

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Nov 22 09:37:37 PST 2011


Range error actually has fairly limited usage in the current specification.  Enough so, that it arguably doesn't carry its weight as one of the very few available exceptions "classes".    I think we could reasonably drop the "numeric" from its prose description and use it for all (new) situations where a provided value is of the correct "type" but outside the set of acceptable values of that type. 

Is there really any situation where it would make sense for an exception handler to filter for  numeric range error but would exclude non-numeric range errors?  I find it implausible as ES exceptions just aren't that precisely identified.

Unfortunately, as it now stands  you have to use the implementation dependent message property value to actually identify specific exceptions.

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.

Allen

 




On Nov 21, 2011, at 5:11 PM, Norbert Lindenberg wrote:

> At last week's TC39 meeting, I asked which error objects an API should throw when it expects a string matching a specific pattern, but receives a string that doesn't match the pattern. Examples in the Globalization API are language tags, as defined in RFC 5646, or selectors such as "sort" and "search".
> 
> Candidates are:
> 
> - RangeError - "Indicates a numeric value has exceeded the allowable range." The Language Specification uses it only for that purpose.
> 
> - TypeError - "Indicates the actual type of an operand is different than the expected type." Used in the Language Specification not only for differences in "type" as defined in the spec, but also when properties are missing, when objects or properties don't have the attributes needed by an algorithm, or when the [[class]] internal property doesn't have the expected value. The Array.prototype.reduce* functions throw it when a required argument is missing, and the RegExp constructor when an unwanted argument is present. JSON.stringify throws it when given a cyclic structure.
> 
> - ValueError - as introduced in the Globalization API spec.
> 
> ValueError would be unnecessary if the definition of RangeError or TypeError were expanded to cover string value mismatches as well.
> 
> Which way should we go?
> 
> Thanks,
> Norbert
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 



More information about the es-discuss mailing list