Even though I contributed the suggestion, I agree with Allen. It is already way too late to pretend that JS is a language in which it is useful to dispatch on the type of error. Given that, let's leave well enough alone and not introduce more error types for any reason other than legacy compat (i.e., with existing DOM practice).
On Tue, Aug 6, 2013 at 1:02 PM, Allen Wirfs-Brock <al...@wirfs-brock.com>wrote: > > On Aug 6, 2013, at 12:40 PM, Brendan Eich wrote: > > > Allen Wirfs-Brock wrote: > >> We did discuss this, as record in > https://bugs.ecmascript.org/show_bug.cgi?id=224 , and concluded that we > it we didn't want to add any new built-in exceptions. Of the existing > exceptions , RangeError is closest in concept to what might be described as > ValueError. > > > > I'd be ok with adding DomainError -- dual, as Mark says -- cheap > one-time addition, not repeated, sold out performance, retired and tax > fugitive after ;-). > > See like a distraction to reopen an issue we already decided. > > Also don't really see that it helps much. Right now, API designer have to > make a decision about the murky distinction between TypeError (sometimes > "type" is interpreted very loosely) and RangeError. Adding DomainError > would probably just add to the confusion and in the end it probably makes > no difference. Has anybody ever actually seen a JS exception handler that > really needs to take conditional action depending upon whether as TypeError > or RangeError was thrown? > > Allen > > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- Text by me above is hereby placed in the public domain Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
