Conditional catch clause

John J Barton johnjbarton at johnjbarton.com
Thu Dec 20 11:48:05 PST 2012


On Thu, Dec 20, 2012 at 11:20 AM, Brendan Eich <brendan at mozilla.com> wrote:

> John J Barton wrote:
>
>  On Wed, Dec 19, 2012 at 11:43 PM, Brendan Eich <brendan at mozilla.com<mailto:
>> brendan at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121220/ff17a2a1/attachment-0001.html>


More information about the es-discuss mailing list