A way of explicitly reporting exceptions

Kevin Reid kpreid at google.com
Mon Jun 23 12:35:08 PDT 2014

On Mon, Jun 23, 2014 at 12:08 PM, Tab Atkins Jr. <jackalmage at gmail.com>

> On Mon, Jun 23, 2014 at 11:54 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> >   for (listener of listeners) {
> >     try {
> >       listener();
> >     } catch (e) {
> >       // Now what?
> >     }
> >   }
> Can't you just pass e into a setTimeout()'d callback, and rethrow it
> from there?  Does that mess with the stack or something?

Yes, but setTimeout may be less prompt than you want depending on the
application (though another possibility is to use promises to queue it).
You might also have an application-specific reason to do something after
all the listeners (some kind of "buffer flush").

However, I'd like to propose a different facility: Instead of "catch and
then report", have a "try and stop propagation but don't catch". This has a
nifty advantage in debuggability: you can declare that a debugger's "stop
on uncaught exception" should stop on such errors _before the stack is
unwound_. This makes it much easier to debug errors in listeners, because
you don't have to step through all other caught exceptions in order to stop
on that exception.

This can be done without a new language construct by making it a primitive

    callAndRedirectErrors(function () {

which is equivalent to, in the absence of a debugger,

    try {
    } catch (e) {
        <log e to console, etc>

In the presence of a debugger, it has the special behavior that any errors
which _would_ be caught by that catch block _instead_ are stopped on if
uncaught exceptions would be — that is, before the stack is unwound.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140623/fec3b5e7/attachment.html>

More information about the es-discuss mailing list