Conditional catch clause

Brendan Eich 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
>>> non-errors.
>>
>> 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 
> possibility>

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 
compatibility constraint.

/be


More information about the es-discuss mailing list