W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

RE: Exceptions in event listeners triggered by dispatchEvent().

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Tue, 4 Jun 2013 15:19:34 +0000
To: Glenn Maynard <glenn@zewt.org>, John Barton <johnjbarton@google.com>
CC: johnjbarton <johnjbarton@chromium.org>, "www-dom@w3.org" <www-dom@w3.org>, Anne van Kesteren <annevk@annevk.nl>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F877D0028@BY2PRD0510MB354.namprd05.prod.outlook.com>
From: Glenn Maynard [glenn@zewt.org]

> Using the event loop system just to change the way an exception is handled doesn't make any sense to me.

Really? To JavaScript programmers, it's the only thing that makes sense. There is no way in native JavaScript semantics to do the magic thing the web platform currently does, wherein (a) code is executed synchronously, but (b) exceptions thrown from that code bypass any surrounding `try`/`catch` blocks, and instead reach `window.onerror`.

>From the perspective of reducing magic in the platform, and providing basic primitives JavaScript programmers can use to polyfill and prollyfill future extensions to the platform, John's objection makes perfect sense. There is black C++ magic going on inside dispatchEvent, and it's unfortunate and surprising to JavaScript programmers.

We can't change it, for legacy reasons. But maybe we could expose that black magic to the platform for developers to use, so that it becomes less magic and more technology, that would allow us to build faithful `dispatchEvent` polyfills.
Received on Tuesday, 4 June 2013 15:20:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:02 UTC