On Thu, Dec 20, 2012 at 11:20 AM, Brendan Eich <bren...@mozilla.com> wrote:
> John J Barton wrote: > > On Wed, Dec 19, 2012 at 11:43 PM, Brendan Eich <bren...@mozilla.com<mailto: >> bren...@mozilla.com>> wrote: > > > In JS, it's a lot easier with >> > the VM support for filtering based on exception type. We're >> working on such VM support in SpiderMonkey, see >> https://developer.mozilla.org/**en-US/docs/SpiderMonkey/JS_** >> Debugger_API_Reference/**Debugger#onExceptionUnwind()<https://developer.mozilla.org/en-US/docs/SpiderMonkey/JS_Debugger_API_Reference/Debugger#onExceptionUnwind()> >> <https://developer.mozilla.**org/en-US/docs/SpiderMonkey/** >> JS_Debugger_API_Reference/**Debugger#onExceptionUnwind%28%**29<https://developer.mozilla.org/en-US/docs/SpiderMonkey/JS_Debugger_API_Reference/Debugger#onExceptionUnwind%28%29> >> >. >> >> >> I'm excited to see this kind of advance. However, as I said earlier, this >> is the smaller part of the impact of non-error exception handling. In >> addition to such APIs as you cite, the specification that separates error >> and non-error exceptions must also be considered. >> > > TC39 is not and will not make any such "global" a-priori specification. > > People expect to subclass Error, the spec already does. That's fair. But > you can throw any value, and real code does use this. Narcissus in the > original metacircular form had very pretty exception-but-not-error throwing > to implement throw, break and continue (including to label), and return: > > https://github.com/**BrendanEich/narcissus/blob/** > master/lib/jsexec.js#L476<https://github.com/BrendanEich/narcissus/blob/master/lib/jsexec.js#L476> > https://github.com/**BrendanEich/narcissus/blob/** > master/lib/jsexec.js#L484<https://github.com/BrendanEich/narcissus/blob/master/lib/jsexec.js#L484> > https://github.com/**BrendanEich/narcissus/blob/** > master/lib/jsexec.js#L512<https://github.com/BrendanEich/narcissus/blob/master/lib/jsexec.js#L512> > https://github.com/**BrendanEich/narcissus/blob/** > master/lib/jsexec.js#L517<https://github.com/BrendanEich/narcissus/blob/master/lib/jsexec.js#L517> > > > Depending on the design, this could be anywhere from "only errors raise >> exceptions" to "developers must supply a algorithm to decide". Languages >> with a centrally controlled type system (I have in mind Java) provide a >> relatively simple way to separate these exceptions. >> > > And how is this relevant? I'm not snarking back. JS != Java. Java is one example of a language that supports non-error uses of the try/catch exception mechanism. Part of that support includes a way for debuggers to distinguish errors uses from non-error uses. Encouraging additional non-error use of the JavaScript try/catch mechanism without a similar means to separate them from error uses will make features like onExceptionUnwind tedious for developers to use. jjb
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
