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
https://developer.mozilla.org/en-US/docs/SpiderMonkey/JS_Debugger_API_Reference/Debugger#onExceptionUnwind().
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
issue.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
