On Mon, Nov 21, 2011 at 5:11 PM, Norbert Lindenberg <[email protected]> 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?
Just use Error and focus you energy on creating useful content in the error object. jjb _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
