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

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

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 3 Jun 2013 17:36:53 -0500
Message-ID: <CABirCh_2my3GE4mFLr8MkgOwLK=Wv1-JL4=nJ=YDYS22=PCxVg@mail.gmail.com>
To: John Barton <johnjbarton@google.com>
Cc: johnjbarton <johnjbarton@chromium.org>, "www-dom@w3.org" <www-dom@w3.org>, Anne van Kesteren <annevk@annevk.nl>
On Mon, Jun 3, 2013 at 10:14 AM, John Barton <johnjbarton@google.com>wrote:

> Yes, thanks, I can see that the error can not prevent other handlers, so
> the error cannot be propagated back to the caller.
> So the problem that remains is the synchronous call.  That is what set my
> expectations for a propagated error in the first place.
> To say this another way: IMO the call to dispatchEvent() should queue the
> event and continue execution.  All of the event listeners should run on
> their own event loop turn.

This is a widely-used API, it's years too late to change this.

You could add a new API, eg.

obj.dispatchEventAsync(event, function(resultEvent) {
if!(resultEvent.defaultPrevented) { console.log("Continue"); } });

but I don't think that would add anything useful to the platform.
 Functions are made asynchronous if they need to be, such as when the
result needs to block on I/O.  It's only a hassle when it's not needed.

By the way, I disagree with the assumption that exceptions not propagating
implies that a function is asynchronous.  Asynchronous operation implies
you can't propagate exceptions at the call point, but that doesn't imply
that if you don't propagate exceptions at the call point you're

Glenn Maynard
Received on Monday, 3 June 2013 22:37:26 UTC

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