On Wed, Dec 19, 2012 at 11:43 PM, Brendan Eich <[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. I'll give a specific example below. 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. > 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? > > 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()> > . 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. 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. > > 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. > > > 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. > 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. > > 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? 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. jjb
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
