John J Barton wrote:
On Wed, Dec 19, 2012 at 11:43 PM, Brendan Eich <[email protected]
<mailto:[email protected]>> 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
https://developer.mozilla.org/en-US/docs/SpiderMonkey/JS_Debugger_API_Reference/Debugger#onExceptionUnwind()
<https://developer.mozilla.org/en-US/docs/SpiderMonkey/JS_Debugger_API_Reference/Debugger#onExceptionUnwind%28%29>.
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:
https://github.com/BrendanEich/narcissus/blob/master/lib/jsexec.js#L476
https://github.com/BrendanEich/narcissus/blob/master/lib/jsexec.js#L484
https://github.com/BrendanEich/narcissus/blob/master/lib/jsexec.js#L512
https://github.com/BrendanEich/narcissus/blob/master/lib/jsexec.js#L517
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. ES.next 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 :-).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
