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

On Wed, Jun 5, 2013 at 6:10 AM, Anne van Kesteren <[email protected]> wrote:

> On Tue, Jun 4, 2013 at 6:47 PM, Boris Zbarsky <[email protected]> wrote:
> > On 6/4/13 11:19 AM, Domenic Denicola wrote:
> >> 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`.
> >
> > Uh... Sure there is.  It's as simple as a function that catches the
> > exception and then calls window.onerror, no?
>
> Given the likely outcome of
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22185 running the
> script as a fresh code entry-point is a special kind of semantics, I
> think. When TC39 tries to rationalize script execution they'll have to
> take this into account (among many other things).
>

At present the bug you cite indicates that all the listeners for a
dispatchEvent() call (and recursively if they call dispatchEvent()) will
result in a single microtask, causing all of their DOM and object mutations
to be reported at a single time. If this means that the mutations cannot be
logically connected to the correct listener invocations, this is a terrible
outcome.

Just to try to draw a connection to the try/catch discussion, I think one
change between now and the days when dispatchEvent was invented is our
increased understanding and reliance on the JS event turn as a unit of
computation. JS developer think in terms of turns and they use the few dull
tools like setTimeout to manipulate the event loop. That is why I believe
the current behavior of dispatchEvent() seems odd to us now while it may
not have seemed so in the past.

jjb


>
>
> --
> http://annevankesteren.nl/
>
>