Conditional catch clause

John J Barton johnjbarton at johnjbarton.com
Wed Dec 19 15:31:20 PST 2012


On Wed, Dec 19, 2012 at 11:23 AM, Brendan Eich <brendan at mozilla.com> wrote:

> John J Barton wrote:
>
>  On Wed, Dec 19, 2012 at 8:11 AM, Brandon Benvie <
>> brandon at brandonbenvie.com <mailto:brandon at brandonbenvie.**com<brandon at brandonbenvie.com>>>
>> wrote:
>>
>>     The magical quality that throw has is its ability to end multiple
>>     call frames at once. Much like a second continuation channel, or
>>     the error channel in a promise, it escapes past any number of
>>     listeners on the normal channel, only stopping at the first
>>     listener on the error channel.
>>
>>
>> Well said: it's always possible to argue for 'goto' in specific cases.
>> With experience we've learned that these seemingly sensible features have
>> debilitating system effects.
>>
>
> Which sensible features do you mean? Termination-style exception handling,
> meaning 'throw'?
>

goto, and similar control transfers. 'throw' has proven to be a useful
exception ... because we use it for exceptions.


>
> JS1 had no try/catch so too many fail-soft silence-is-deadly conditions.
> This is a big problem still.
>
> ES3 added try/catch and it has been a mixed bag, but as Brandon points
> out, you can terminate multiple frames (dynamically linked -- no static
> confinement) with exceptions. This is important for one of two prevailing
> use-cases for try/catch:
>
> 1. Local protocols where a producer needs to terminate an iteration
> without a-priori coordination with arbitrary consumers, including
> specifically without a magic OOB value meaning "stop".
>
> 2. Long-distance try/catch near the event loop, to deal with some poorly
> understood but recoverable problem in subsystem (e.g., the DOM, XPCOM, COM
> or Windows8, etc. etc.)
>
> The value of (2) is low but real.
>

I disagree. (2) is essential exactly because we depend on subsystems.


>
> StopIteration is only one example of (1).


And one too many, exactly because (2) is so vital.  We should not pollute
the critical feature of "throw exceptions" with "throw because I can't
figure out another implementation"


>
>
>  The mistake of including StopIteration should not be used to justify
>> including more mistakes.
>>
>
> This is Crockfordian in its dire sweep but I don't think you've made the
> case. What's your preferred alternative?


Don't include features that require StopIteration.


>
>
>  Communicating two different non-error results through the normal return
>> channel is not easy,
>>
>
> How?


Sorry, I should have said: finding a way to implement StopIteration without
using the throw-exceptions channel may not be easy, but it does not seem
impossible.

jjb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121219/a2c647ed/attachment.html>


More information about the es-discuss mailing list