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

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

> On Mon, Jun 3, 2013 at 6:33 PM, John Barton <johnjbarton@google.com>wrote:
>
>>  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.
>>
>
> It's not hard.  I've written plenty of code myself that would break
> completely if it didn't dispatch the event synchronously.  This is a basic
> pattern:
>
> function doSomething(element) {
>     var e = new Event("someEvent", { cancelable: true });
>
>     // Dispatch the event.  If any listener calls stopPropagation, return
> without doing anything else.
>     if(!element.dispatchEvent(e))
>         return;
>
>     // Nobody cancelled the event, so do our default action.
>     doSomethingElse(element);
> }
>
>
>> 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.
>>
>
> That doesn't give you access to the resulting state of the event, which is
> a key part of the event model.
>

Well the current API only gives our part of the result state: why don't the
exceptions propagate?

Why can't we have "dispatch(event)" that both returns your boolean and
propagates exceptions?


>
>
>> 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.
>>
>
> The same ways that you understand the details of any API: documentation
> and experience.  I don't think "if a function doesn't propagate exceptions,
> then it's asynchronous" is a good goal--that's even wackier.
>

I thought we established that dispatchEvent()'s behavior is not documented.
What experience would I use other that years of experience in JavaScript?


>
> Making APIs asynchronous makes them much more cumbersome to use.
>

I don't want the API to be asynchronous. I want the feature to act like
every other JS function and propagate exceptions unless it schedules
operations on another event turn.

Anyway we don't need to continue, it is what it is and it does not sound
like there is any chance of change. Thanks for your time in explaining
things, it really is helpful even if the outcome is not what I like.




> Making APIs asynchronous for something like this is introducing a very big
> inconvenience to try to solve a very minor one.  (And adding a second
> asynchronous API alongside dispatchEvent doesn't solve anything--now you
> have two similar-looking functions with different behavior, which isn't
> likely to make anything clearer.)
>
> --
> Glenn Maynard
>
>