On Tue, Nov 22, 2011 at 10:49 AM, Allen Wirfs-Brock <[email protected]> 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. >> >> *Error.prototype.name 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). jjb _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
