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

Glenn Maynard <[email protected]>
Newsgroups gmane.comp.web.dom.general
Message-ID <CABirCh_2my3GE4mFLr8MkgOwLK=Wv1-JL4=nJ=YDYS22=PCxVg@mail.gmail.com>
On Mon, Jun 3, 2013 at 10:14 AM, John Barton <[email protected]>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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.