Error objects: RangeError, TypeError, ValueError
brendan at mozilla.com
Tue Nov 22 10:14:00 PST 2011
On Nov 22, 2011, at 9:37 AM, Allen Wirfs-Brock wrote:
> 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.
Pedants and wannabes like me will object to "Range" instead of "Value" (codomain vs. domain :-P). But agreed, we could use RangeError in more places; we could do worse.
> 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.
*Error.prototype.name is normatively specified for all the built-in Error constructors.
> 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.
Folks who were around for ES3 should weigh in, in case we're missing something that can be improved in the *Error design originated in that spec. IIRC it was from TC39 TG1, design by committee or a champion on that task group. It was not from implementation-led de-facto standards.
> 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?
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss