Are thrown errors in a try block considered to be handled even if there's no catch block?

[T.J. Crowder]

> Are thrown errors in a try block considered to be handled
> even if there's no catch block?

An exception propagates out of a function (and thus is ultimately reported
unhandled if unhandled) if it's what terminates the function. If code in
the `finally` block does something to prevent the original exception
terminating the function (by continuing a loop within the function,
returning something, throwing a different exception, etc.), then the
(original) exception doesn't propagate.

> If you swap out the catch block for a finally block (with either
> `continue` or some kind of recursive iteration), the errors
> aren't technically handled, but only that last one is
> considered "uncaught".

The last one will only be special if you treat it differently from the
previous ones. I *think* you mean something like this:

```js
for (let i = 0; i < 3; ++i) {
    try {
        throw i; // E.g., code that may throw
    } finally {
        if (i < 2) { // If we're not on the last iteration
            continue;
        }
    }
}
```

There, by using `continue` in the `finally` block (for all but the last
one), we're preventing the exception from propagating because we've changed
the completion of the block from 'throw' to 'continue', details:

* [The `continue` statement - Runtime semantics - Evaluation][1]
* [The `try` statement - Runtime semantics - Evaluation][2]
* and the various loop definitions, for instance [The `for` statement -
Runtime semantics - ForBodyEvaluation][3].

I think that's the answer to your question about `finally`.

The core issue you're having, replicating `dispatchEvent`'s behavior, is
fascinating; I don't think you can do what it does (at least, what it does
on Chrome), because it calls the handlers *synchronously*, allowing their
exceptions to propagate (synchronously), but also continuing its
synchronous loop through the handlers. I found the results of this code
fascinating, for instance (https://jsfiddle.net/krdqo1kw/):

```js
Promise.resolve().then(_ => console.log("then"));
const target = document.createElement('div');
target.addEventListener('foo', e => {
    console.log("1");
    throw 1;
});
target.addEventListener('foo', e => {
    console.log("2; cancelling");
    e.stopImmediatePropagation();
    throw 2;
});
target.addEventListener('foo', e => {
    console.log("3");
    throw 3;
});
target.dispatchEvent(new CustomEvent('foo', {cancelable: true}));
console.log("dispatch complete");
```

On Chrome, I get:

```
1
Uncaught 1
2; cancelling
Uncaught 2
dispatch complete
then
```

...where the uncaught exception traces point to the `throw` line in the
relevant event handler. Very nice. Note the synchronous processing. I
should dive into the source, but clearly it's creating a job and running it
synchronously (or code to that effect), and since the exceptions aren't
handled by anything in the job, they get reported as unhandled.

On Firefox, I get

```
1
2; cancelling
dispatch complete
then
uncaught exception: 1
uncaught exception: 2
```

...where the traces point to the `dispatchEvent` line. So it seems to store
them up and then report them.

Replicating the Firefox behavior in your own `dispatchEvent` function is
fairly doable: Catch the exceptions, store them, and then fire them off
asynchronously when done (https://jsfiddle.net/gwwLkjmt/):

```js
class Publisher {
    constructor() {
        this.subscribers = new Set();
    }
    subscribe(f) {
        this.subscribers.add(f);
    }
    trigger() {
        const exceptions = [];
        const event = {cancel: false};
        for (const f of this.subscribers) {
            try {
                f(event);
            } catch (e) {
                exceptions.push(e);
            }
            if (event.cancel) {
                break;
            }
        }
        for (const e of exceptions) {
            setTimeout(_ => { throw e; }, 0);
        }
    }
}
const target = new Publisher();
target.subscribe(e => {
    console.log("1");
    throw 1;
});
target.subscribe(e => {
    console.log("2; cancelling");
    e.cancel = true;
    throw 2;
});
target.subscribe(e => {
    console.log("3");
    throw 3;
});
target.trigger();
Promise.resolve().then(_ => console.log("then"));
```

On Chrome, those traces point to our `setTimeout` line; on Firefox, they
don't have a source. Not really ideal we have to wait for the next
macrotask to report the exceptions, but it lets us run the handlers
efficiently while still getting the engine to report the unhandled
exceptions in its usual way. (Using `Promise.resolve().then(_ => { throw e;
})` would at least put them on the task's microtask queue, but it would
mean they'd be reported as unhandled rejections rather than unhandled
exceptions.)

I can't see how to replicate Chrome's behavior though.

-- T.J. Crowder

[1]: https://tc39.github.io/ecma262/#sec-continue-
statement-runtime-semantics-evaluation
[2]: https://tc39.github.io/ecma262/#sec-try-statement-
runtime-semantics-evaluation
[3]: https://tc39.github.io/ecma262/#sec-forbodyevaluation

On Fri, Jun 23, 2017 at 10:20 AM, Andy Earnshaw <andyearnshaw at gmail.com>
wrote:

> A long trip down a rabbit hole has brought me here. Long story short(ish),
> I was attempting to replicate how `EventTarget.prototype.dispatchEvent()`
> works in plain JavaScript code. A naive implementation (like Node's
> EventEmitter) would simply loop over any bound handlers and call them in
> turn.  However, this isn't very robust because one bound handler can
> prevent the rest from executing if it throws.
>
> DOM's dispatchEvent() doesn't have this problem.  Consider the following
> code:
>
> ```
> target = document.createElement('div');
> target.addEventListener('foo', () => { throw 1; });
> target.addEventListener('foo', () => { throw 2; });
> target.addEventListener('foo', () => { throw 3; });
> target.dispatchEvent(new CustomEvent('foo'));
> ```
>
> If executed in a browser, I see:
>
> > Uncaught 1
> > Uncaught 2
> > Uncaught 3
>
> Even though each one throws, they all still execute.  In our naive
> implementation, if you wrap each callback with a try/catch, errors thrown
> become handled, so the callback provider might not be aware of errors or it
> may be difficult to debug them without a stack trace. Global error handlers
> aren't triggered either.  If you swap out the catch block for a finally
> block (with either `continue` or some kind of recursive iteration), the
> errors aren't technically handled, but only that last one is considered
> "uncaught".
>
> I've observed this behaviour in current versions of Chrome, Firefox and
> Safari.  Does that mean the spec defines finally blocks to behave this way,
> or is it just an implementation-dependant behaviour they've all converged
> on?
>
> PS I realise that dispatchEvent's behaviour stems from it creating a new
> job for each handler function.  Interestingly, you can achieve something
> similar in browsers by appending a new script element per handler function
> to call it.  Not great for performance or achieving this transparently, but
> it works as a sort of proof-of-concept.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170623/a8c97093/attachment-0001.html>