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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC