Conditional catch clause

Brendan Eich brendan at mozilla.com
Wed Dec 19 19:55:57 PST 2012


John J Barton wrote:
> On Wed, Dec 19, 2012 at 11:23 AM, Brendan Eich <brendan at mozilla.com 
> <mailto: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>
>         <mailto: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'?
>
>
> goto, and similar control transfers. 'throw' has proven to be a useful 
> exception ... because we use it for exceptions.

Good, we agree (not sure what you meant by debilitating system effects, 
though -- not disagreeing, just unclear!).

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

Disagree on "low" or "real"? Evidently not "real", so must be "low". 
What I mean is using try/catch near the event loop to drop a "do not 
understand" exception on the floor instead of allowing it to terminate 
the loop (or do whatever an uncaught exception would do) is pretty 
low-value. Perhaps the event loop auto-restarts without a catch. Is the 
canonical console.log of the uncaught exception useful? Only if a 
developer is watching.

My "low" does not mean "zero" -- that would take away the "real" value I 
ascribed. But it's pretty silly to say that try/catch for (2) is highly 
useful, in the sense that it adds a lot of value. If event loops 
auto-respawn it's at best a convenience and logging opportunity.

>
>     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 two use-cases are almost always disjoint. StopIteration is almost 
always auto-handled by for-of constructs.


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

The alternatives are worse. We've been over this. If you don't have 
something new to propose, you're not going to move the needle here at all.

/be


More information about the es-discuss mailing list