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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
