Conditional catch clause

John J Barton johnjbarton at
Thu Dec 20 14:07:45 PST 2012

On Thu, Dec 20, 2012 at 12:38 PM, Brendan Eich <brendan at> wrote:

> John J Barton wrote:
>>         Depending on the design, this could be anywhere from "only
>>         errors raise exceptions" to "developers must supply a
>>         algorithm to decide". Languages with a centrally controlled
>>         type system (I have in mind Java) provide a relatively simple
>>         way to separate these exceptions.
>>     And how is this relevant? I'm not snarking back. JS != Java.
>> Java is one example of a language that supports non-error uses of the
>> try/catch exception mechanism. Part of that support includes a way for
>> debuggers to distinguish errors uses from non-error uses. Encouraging
>> additional non-error use
> Again, I object. StopIteration is not "encouraging additional non-error
> [uses of try/catch]" outside of specialized, written-by-experts libraries
> such as
> The exceptions-are-not-all-errors cat is out of the bag. You don't seem to
> agree but you haven't rebutted directly. I cry foul.

But I do agree! It's Claude that proposes to release the cat. It's Claude
proposal we are discussing, not StopIteration, you've already declared it
out of bounds.

>  of the JavaScript try/catch mechanism without a similar means to separate
>> them from error uses
> Again, without a type system, how?

Hmm: maybe some as trivial as a property 'isNotException'. Mandated on
StopIteration, allowed on user objects.

> Testing catch (e if e instanceof Error) was an explicit intended use of
> catch guards from the ES3 days. With standard catch you would write an
> if-else chain and remember to re-throw in final else. This is quite doable
> now, so what's the problem?

I will try again to explain the problem. When
  throw x;
is executed the debugger can gain control and alert the developer of the
throw. If the throw is an error condition the developer did not expect, the
alert guides them to improve the code. However, if the debugger alerts
often for conditions that are not important, the developer will turn off
the alert feature. The result is a poorer tool. Thus we seek near zero
false positive alerts.  This much I believe you understand.

Testing catch (e if e instanceof Error) is fine for developers but the
similar test in the debugger a list of rules like "e instanceof Error".
Unless the rules are standard, they will need to be entered and maintained
by developers.

So yes this is 'doable' but it creates a large cost on the alert feature.
Debuggers can each invent an ad hoc list of rules but if the fail or even
differ across debuggers, the feature will fail to alert or alert too often,
effectively preventing developers from using the feature.  I hope this is

> Note that DOMException instanceof Error per*
> *es-exceptions <>.
> Yes, instanceof does not work cross-frame. This has been debated on
> es-discuss a lot. For same-realm uses, it suffices, as people here have
> pointed out recently. Exception catching may favor same-realm, I'm not
> sure. But this is a separate issue.
>  will make features like onExceptionUnwind tedious for developers to use.
> This is just the lowest tier of the API and we're not done yet.
> To be frank, I think your frustration is perfectly understandable, but not
> grounds for general exhortations or judgments against particulars
> (StopIteration) that are not relevant (for-of handles outside of
> specialized taskjs settings), or at the very least not decisive in light of
> precedent (instanceof Error testing). Anyway, I hope to have shed some
> light here. How'd I do?

Happy Holidays!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list