Note first that I was trying to summarize the broad dimensions of the alternatives discussed, not outline spec-quality proposals.
On Tue, Jun 24, 2014 at 2:43 PM, Jason Orendorff <[email protected]> wrote: > On Tue, Jun 24, 2014 at 8:38 AM, C. Scott Ananian <[email protected]> > wrote: > > I am ambivalent about where it goes; it depends to some degree with > > how the feature is implemented. > > > > `setTimeout(function() { throw e; }, 0);` is ugly, but it seems to > > have most of the behavior you want. > > What. Strongly disagree. Timing matters! > Yes. Hence "most", etc. I was eliding the whole discussion of synchronous-vs-asynchronous, etc. See other messages by other people for that. I was just noting that one broad direction was to build on the existing handling of "uncaught exceptions in jobs". There are lots of details here, timing included, as others have discussed. But fundamentally this option is "provide direct access to the already existing job/task/turn mechanism, using the uncaught exception handler already specified there". [I'm going to call this option "a".] > > Finally, it hasn't been discussed much, but some platforms provide > > explicit access to the 'uncaughtException' handler. > > +1. This feature would be a complement to what bz proposed. Either > feature could be added and used independently from the other. > We'll call this option "c", after the ordering in my original message. Note that I elided lots of details here, as well. Python, for example, allows you to access `sys.excepthook` as an ordinary function object, so you can save a reference and invoke it later, add a chained handler that defers to the stock handler in certain circumstances, etc. Node fires an event for an uncaught exception; I don't think that it is straightforward to reach inside the handler chain for this the way you do in python. You can have multiple handlers, though! And the handlers are scoped to a specific `process` object. Several commenters on this thread expressed the desire to log stack traces to console/set breakpoints/etc *without* halting execution, for example when dispatching handlers. Only something based on `console.trace` (which we'll call "option b") seems to have that ability at the moment -- if you "invoke the default uncaught exception handler" (either via a synchronous job/task/turn mechanism or by direct access to the uncaught exception handler), you have to expect that default handler may halt execution. Which is just to say that there are lots of options here and I'm not sure exactly which spec it belongs with. I fear that we will end up with three different overlapping-but-slightly-differing mechanisms, based on (a) jobs/tasks/turns, (b) the console object, and (c) some sort of platform-specific access to the default uncaughtException handler. Perhaps the solution is to work on this initially as a new "cross-platform" spec, akin to "console", which can tackle all three aspects at once. --scott
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
