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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
