On Wed, Dec 19, 2012 at 11:23 AM, Brendan Eich <bren...@mozilla.com> wrote:
> John J Barton wrote: > > On Wed, Dec 19, 2012 at 8:11 AM, Brandon Benvie < >> bran...@brandonbenvie.com >> <mailto:brandon@brandonbenvie.**com<bran...@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. > > 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, >> > > How? 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 impossible. jjb
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
