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