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

On Mon, Jun 3, 2013 at 3:36 PM, Glenn Maynard <glenn@zewt.org> wrote:

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

I understand this limitation and how hard it may be to know if the current
behavior is the only one which can work.


>
> You could add a new API, eg.
>
> obj.dispatchEventAsync(event, function(resultEvent) {
> if!(resultEvent.defaultPrevented) { console.log("Continue"); } });
>

Sorry, this is not at all what I had in mind. Rather:
   targetElement.dispatch(event); // all listeners run on future turns, we
continue, no blocking, no join.


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

Maybe I am using the words synchronous/asynchronous incorrectly.

Consider the following code, assuming one of the listeners throws:
----
   try {
     targetElement.dispatchEvent(evt);
   } catch(exc) {
     console.log("A listener had a error");
     return;
   }
   goOnToGlory();
----

How can a developer know that the catch block can never be executed and yet
exceptions in handlers are reported as uncaught? The only other experience
that I know about which accounts with these two facts is that
dispatchEvent() schedules listener executions on another event turn.  But
it doesn't, it's just another wacko Web behavior we have to look up and
memorize.

jjb