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

On Mon, Jun 3, 2013 at 10:48 PM, John Barton <johnjbarton@google.com> wrote:

> Ultimately targetElement.dispatchEvent(event) has a primary job: queue
> events for processing in the same way that events are queued when we
> interact with the UI. (We don't need dispatchEvent(), we could call the
> handlers directly if we want, so why don't we? Because we want to emulate
> the event handling).
>

dispatchEvent's job is to dispatch events.  Queueing isn't part of its
job.  dispatchEvent is the JavaScript analog to saying "dispatch an event"
or "fire an event" in specs, and when you say "fire an event named foo" in
a spec, that doesn't queue a task.  When a spec wants that, it wraps it in
a task, eg. "queue a task to fire an event", and that's very often not
wanted.

That primary job got compromised when the the fundamentally asynchronous
> mission was shoe horned in to a synchronous call with a return value. We
> cannot achieve a consistent result from two fundamentally inconsistent
> goals.
>

On the contrary, event dispatch is fundamentally synchronous.  It's
sometimes nested in an asynchronous algorithm, but event dispatch doesn't
care about that.

If we want all of the listener to run independent of the outcome of the
> other listener invocations, then we should use the wonderfully successful
> event loop to achieve this goal.
>

Using the event loop system just to change the way an exception is handled
doesn't make any sense to me.  (Also, here you seem to be suggesting that
each listener should be its own task on the event queue.  That would mean
other tasks would be allowed to run between listeners on the same event,
which would be very bad.)

-- 
Glenn Maynard