John J Barton wrote:
On Wed, Dec 19, 2012 at 11:23 AM, Brendan Eich <[email protected]
<mailto:[email protected]>> wrote:
John J Barton wrote:
On Wed, Dec 19, 2012 at 8:11 AM, Brandon Benvie
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
