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

> On Mon, Jun 23, 2014 at 11:54 AM, Boris Zbarsky <bzbar...@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
function:

    callAndRedirectErrors(function () {
        listener();
    });

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

    try {
        listener();
    } 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.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to