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

[Andy Earnshaw]

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

Indeed it is, thank you.  I'd read before about propagation of exceptions
but I was having trouble pinning down where this happens in the spec text.

> 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.

The other downside is that "break on exceptions" in the debugger will break
in the wrong place with the wrong stack trace (you'd have to break on
caught exceptions, which includes all the noise from other caught
exceptions).

On Fri, 23 Jun 2017 at 12:01 T.J. Crowder <tj.crowder at farsightsoftware.com>
wrote:

> > 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/6e80a606/attachment-0001.html>