Conditional catch clause

John J Barton johnjbarton at
Thu Dec 20 14:47:41 PST 2012

On Thu, Dec 20, 2012 at 2:16 PM, Brendan Eich <brendan at> wrote:

> John J Barton wrote:
>> On Thu, Dec 20, 2012 at 12:38 PM, Brendan Eich <brendan at<mailto:
>> brendan at>> wrote:
>>     John J Barton wrote:
>>         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.
> I will avoid taking the StopIteration bait liberally sprinkled amidst the
> discussion :-P.
> I would not say anything is "out of bounds", but StopIteration is just an
> example of non-error exceptions. It may stand out to some (we've shipped it
> since 2006 without a lot of pain on the debugger side -- or any, from my
> view of bugzilla [let me know if I missed a bug]) but the general ability
> to throw any value for dynamic control effects has been around since 1999,
> and it does see some use in the field.
> So perhaps I'm just fussing over a point of order, but these fine points
> seem important to strive to agree on, or disagreement will spring up again
> based on different assumptions.

Sorry I misread you. Your point is that Claude need make no proposal
because it's a done deal.  I believe ES explicit adoption of this approach
could dramatically increase its use.

>>         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.
> Don't you mean isNotError or isNotErrorException?
> Would you put it on Object.prototype?
> It seems to me the (e instanceof Error) test is better, but there could be
> a duck-typing convenience. Perhaps "isErrorException" would be best, so you
> don't need to ensure it exists -- then the default undefined value converts
> to false. Perhaps there's a better name. We should focus on this if it's
> what you seek.

A lot of real code throws strings, for example from WebInspector:

throw "invalid color format";

Thus I suggest assuming that thrown objects are ErrorExceptions unless the
standard (eg StopIterator) or developer marks them isNotErrorException.
 This path would also allow runtimes to optimize throwing such objects,
perhaps avoiding some overhead required for exception handling.

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

More information about the es-discuss mailing list