Conditional catch clause
brendan at mozilla.com
Wed Dec 19 23:47:30 PST 2012
Herby Vojčík wrote:
> Brendan Eich wrote:
>> John J Barton wrote:
>>> Unless we have foolishly polluted our error handling mechanism with
>> Exception-handling > error-handling. Perhaps we disagree, but it's not
>> called "error-handling" -- it is called "exception handling" for good
>> reason. Exceptional conditions are not all errors.
> But polluting single physical channel with all the orthogonal logical
> channels is at least questionable, isn't it?
Adding exception channels at least avoids adding another value
type/singleton. But I don't see how it works. More below.
> Is the idea of multiple channels (as I posted a few mails ago) not a
I doubt it will gain champions. Once you have try/catch/finally, you've
got enough to build such things via libraries. Adding channels under the
hood doesn't help hide StopIteration, since control flow must stop and
unwind when it is thrown. We can't blast past default-channel
try/catch/finally's seeking one that handles StopIteration, we must at
least run the finally clauses.
But those finally clauses if written for ES3 or above will assume that
any abrupt completion was a default-channel exception, i.e, that the
catch clause ran. Your proposal as I understand it breaks that
More information about the es-discuss