A way of explicitly reporting exceptions

[C. Scott Ananian]

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 <jason.orendorff at gmail.com>
wrote:

> On Tue, Jun 24, 2014 at 8:38 AM, C. Scott Ananian <ecmascript at cscott.net>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140624/096b457a/attachment.html>