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