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

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

> On Mon, Jun 3, 2013 at 7:36 PM, John Barton <johnjbarton@google.com>wrote:
>
>>  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?
>>
>
> Sorry, I don't follow.  If it returns the boolean, then the event
> listeners must be run before the function returns.  (The return value tells
> you whether any event listener called event.preventDefault().)  I don't
> know what "propagating exceptions" would mean here, since multiple
> exceptions might be thrown (multiple listeners).  I suppose it could mean
> "run all listeners, then rethrow the first seen exception", but that seems
> weird to me.
>

The current API is weird. It's just a hodgepodge of rules "run all of the
listeners, ignore any exceptions, join the return values of the rest".

Ultimately targetElement.dispatchEvent(event) has a primary job: queue
events for processing in the same way that events are queued when we
interact with the UI. (We don't need dispatchEvent(), we could call the
handlers directly if we want, so why don't we? Because we want to emulate
the event handling). That primary job got compromised when the the
fundamentally asynchronous mission was shoe horned in to a synchronous call
with a return value. We cannot achieve a consistent result from two
fundamentally inconsistent goals.

If we want all of the listener to run independent of the outcome of the
other listener invocations, then we should use the wonderfully successful
event loop to achieve this goal.

event.preventDefault() should queue up just like the event handlers; the
caller wants the handle preventDefault() they register an event listener on
the element and handle it.

The system is event driven, we should use events.


>
> (This is probably academic--I doubt that would be web-compatible
> either--but I'm just trying to understand what you mean.)
>

Indeed, and I'm just trying to articulate an approach that makes sense if
unattainable.


>
>  I thought we established that dispatchEvent()'s behavior is not
>> documented. What experience would I use other that years of experience in
>> JavaScript?
>>
>
> I'm not sure what you're arguing, but improving documentation and specs is
> much simpler than changing or adding new APIs (which would itself require
> changes to specs).
>
> You can do some of it yourself; MDN appears to be open to public editing:
>
> https://developer.mozilla.org/en-US/docs/Web/API/EventTarget.dispatchEvent
>
> (I suspect MDN is used by web developers much more often than reading the
> spec, so if it's author confusion you're worried about, adding a sentence
> in here will probably have more effect than any change to the spec.)
>

Thanks for the suggestion. Unfortunately when I attempt save my change,
that site reports "An unhandled error occurred in the application. ". I
guess their try/catch does not work either :-(.

jjb



>
>
> --
> Glenn Maynard
>
>