Conditional catch clause

Brendan Eich brendan at
Thu Dec 20 11:20:02 PST 2012

John J Barton wrote:
> On Wed, Dec 19, 2012 at 11:43 PM, Brendan Eich <brendan at 
> <mailto:brendan at>> wrote:
>     John J Barton wrote:
>         I'll tell you straight out that TC39 should pay more attention
>         to debugging.
>     How would that work? Debuggers are evolving rapidly, should we
>     standardize one now? TC39 has a good cohort of JS developers who
>     use debuggers in their real jobs. What should we be doing for
>     debuggers _per se_ that we are not?
> TC39 invests and encourages amazing and thorough discussions on 
> compiler-oriented ergonomics of ECMAScript yet the total programming 
> experience includes other issues, especially debugging. Explicitly 
> consider and encourage examination of the debugging implications of 
> language design to improve the total development experience.

We do try. You know AWB has tons of experience here from Smalltalk. 
MarkM, Doug, Alex, Yehuda, Arv, all bring to bear considerable experience.

> I'll give a specific example below.

Great, thanks.

> Obviously not all language features have significant debugger 
> experience issues. But module loading, promises, generators, pragmas, 
> observe, proxies are all things impact on development should be 
> considered.

I'm telling you they have been for those things (especially for pragmas, 
which we deferred). Let's get to specifics, or this could go on and on :-|.

>         Rather than viewing debugging as an optional wagging appendage,
>     I didn't write "optional", and dogs' tails are there for good
>     reason! :-P
>     A language's design may include such things as invariants (e.g.
>     closure variable non-enumerability) that debuggers break.
>     Debuggers break abstractions. This does not mean that languages
>     should provide unprivileged APIs for self-hosting debuggers. That
>     would be a security disaster on the web.
> How might this point be related to the topic under discussion?

Tail = debugging closures including enumerating their environment 
variables. Dog = JS with closures in unprivileged dominant use-case, no 
such debugging APIs.

>     To get back to the specific problem of exceptions: they do get
>     thrown sometimes, and I've had to debug problems where I wanted
>     only one particular throw (from an XPCOM error return code, as it
>     happens, a real pain to track down without debugger support).
>     In C++ this requires great GDB pain. In JS, it's a lot easier with
>     the VM support for filtering based on exception type. We're
>     working on such VM support in SpiderMonkey, see
>     <>.
> I'm excited to see this kind of advance. However, as I said earlier, 
> this is the smaller part of the impact of non-error exception 
> handling. In addition to such APIs as you cite, the specification that 
> separates error and non-error exceptions must also be considered.

TC39 is not and will not make any such "global" a-priori specification.

People expect to subclass Error, the spec already does. That's fair. But 
you can throw any value, and real code does use this. Narcissus in the 
original metacircular form had very pretty exception-but-not-error 
throwing to implement throw, break and continue (including to label), 
and return:

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

>         we should consider debugging as one of the essential elements
>         in success of language features. (And proposing that I think
>         exceptions are the only errors one must debug is just silly ;-).
>     You keep writing "error-handling" when the topic is
>     exception-handling, though. Why is that?
> If some specific statement I made is confusing I'll try to clarify.

Let's try to agree that exceptions as a set subsumes errors (ignoring 
bad old errno-ish patterns in legacy APIs).

>     If you mean by "Claude's proposal" the catch (e if ...) syntax
>     already in SpiderMonkey and Rhino, then I don't follow. The burden
>     for filtering exceptions exists whether one has only catch (e) or
>     catch (e if ...) syntax. With only catch (e), one must hand-code
>     an if-else chain or switch, and worry about re-throwing in the
>     default/final-else case.
>     So how is any new burden imposed by Claude's proposal (catch (e if
>     ...))? It either exists in the structure of the code using
>     exceptions, or it doesn't.
> Claude's proposal says:
> "Rationale: Although try/catch mechanism was initially intended for 
> treating errors, it could be used in normal control flow with 
> non-error condition. sanction this pattern with StopIteration. "
> That is the specific statement I wish to challenge.

Claude's "it could be used in normal control flow" was too subjunctive, 
and as I wrote in an earlier reply, because such non-error exceptions 
are used in the field, and have been since ES3, StopIteration is a red 
herring, or at best one of large-N and a future one at that.

>     What syntax one must use to deal with the burden does not affect
>     the burden's existence or magnitude -- although I contend that
>     having only catch (e) makes missing re-throw bugs likelier.
>         All to save the fans of StopIteration style control flow from
>         doing the right thing in the first place.
>     What "right thing" is that?
>     Your aggrieved and kind of snarky posts may make you feel good,
>     but if you don't have a serious alternative, and if you insist
>     there are no other non-error uses of exceptions, then we'll have
>     to part ways on this issue.
> As I have said before, StopIteration could have been specified with 
> its own control-flow mechanism rather than try/catch/throw. Perhaps it 
> is well known that StopIteration-like uses of try/catch/throw can be 
> cleanly separated from error cases without developer intervention?

By what means? You have not specified. Please, no dry/datch/dinally jokes.

> I'm sorry if my frustration with the crude development tools we have 
> for the Web colors the tone of my posts. They do not make me "feel 
> good"; they just amplify my sense that ES is getting much more complex 
> but we don't have the resources to deal with the consequences in the 
> tools end.

The SpiderMonkey Debugger API is already dealing with extensions we've 
carried for years, e.g. generators. Please look into it before iterating 
frustation :-).


More information about the es-discuss mailing list