Conditional catch clause

Brendan Eich brendan at
Wed Dec 19 23:43:39 PST 2012

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?

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

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

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

>     Debuggers must look inside of closures and get backstage-passes
>     from the GC. They must bear many burdens for the good of the user.
>     Any debugger worth using must be able to
>     stop-on-only-*these*-exceptions, classifying by instance,
>     instanceof/"class", duck-type or other criteria.
> Claude's proposal leads to a small extra burden on debuggers but a 
> much larger and broader burden on developers. It requires developers 
> to build rule sets for exceptions-that-are-not-really-exceptions and 
> to re-enter and maintain these rule sets across many projects and 
> environments.

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.

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 


More information about the es-discuss mailing list