Conditional catch clause

John J Barton johnjbarton at
Wed Dec 19 21:43:56 PST 2012

On Wed, Dec 19, 2012 at 8:01 PM, Brendan Eich <brendan at> wrote:

> John J Barton wrote:
>> Debuggers provide break-on-exception as a valuable development feature.
>> Why? Because developers know that an exception is something the merits
>> special attention.  If we want to invest in throw/catch we should provide
>> features like runtime detection of would-be-caught.
> You seem to be assuming debuggers are the tail that wags the dog, and
> exceptions are only errors that one must debug. Neither is true.

Rather than asking you to guess my assumptions, I'll tell you straight out
that TC39 should pay more attention to debugging. Rather than viewing
debugging as an optional wagging appendage, 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 ;-).

> 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. All to save
the fans of StopIteration style control flow from doing the right thing in
the first place.


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

More information about the es-discuss mailing list