Conditional catch clause

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

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

> John J Barton wrote:
>  On Wed, Dec 19, 2012 at 8:11 AM, Brandon Benvie <
>> brandon at <mailto:brandon at brandonbenvie.**com<brandon at>>>
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list