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>>>
>> 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,
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...
More information about the es-discuss