Conditional catch clause

Brendan Eich brendan at mozilla.com
Wed Dec 19 11:23:47 PST 2012


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

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.

StopIteration is only one example of (1).

> 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?

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

How?

/be


More information about the es-discuss mailing list