Exceptions in event listeners triggered by dispatchEvent().

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Exceptions in event listeners triggered by dispatchEvent().

johnjbarton
When JS calls EventTarget dispatchEvent(evt), EventListener-s are called. If those EventListeners throw exceptions, what should happen if the closest enclosing try/catch block surrounds the dispatchEvent() call?

Both Chrome and Firefox currently ignore the try/catch block and report that the exception is "uncaught". In Chrome, this EventListener is invoked within an internal try/catch (V8::TryCatch) and any exceptions that result are reported as uncaught before returning to the caller (eventually returning to the caller of dispatchEvent()).

I could not find any mention in http://www.w3.org/TR/DOM-Level-2-Events/events.html of the expected result.

I was surprised by the behavior in Chrome and reported:
The little test case is online:

Thanks,
jjb
Reply | Threaded
Open this post in threaded view
|

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

Glenn Maynard
On Fri, May 31, 2013 at 3:28 PM, johnjbarton <[hidden email]> wrote:
When JS calls EventTarget dispatchEvent(evt), EventListener-s are called. If those EventListeners throw exceptions, what should happen if the closest enclosing try/catch block surrounds the dispatchEvent() call?

Both Chrome and Firefox currently ignore the try/catch block and report that the exception is "uncaught". In Chrome, this EventListener is invoked within an internal try/catch (V8::TryCatch) and any exceptions that result are reported as uncaught before returning to the caller (eventually returning to the caller of dispatchEvent()).

I could not find any mention in http://www.w3.org/TR/DOM-Level-2-Events/events.html of the expected result.

This behavior is intentional.  Note that the spec you're reading is over a decade old, the spec you want is http://dom.spec.whatwg.org.  Specifically, see http://dom.spec.whatwg.org/#dispatching-events.

I think exceptions from callbacks are handled explicitly in specs, eg. by saying something like "if the called function throws an exception, ...".  Since the "invoke the event listeners" algorithm (step 4.7) doesn't say to do anything with exceptions, that means that nothing must be done with them, eg. discard them.  (Anne: correct?)  Maybe this could use a note, though.

--
Glenn Maynard

Reply | Threaded
Open this post in threaded view
|

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

Anne van Kesteren-4
On Sun, Jun 2, 2013 at 7:10 PM, Glenn Maynard <[hidden email]> wrote:
> I think exceptions from callbacks are handled explicitly in specs, eg. by
> saying something like "if the called function throws an exception, ...".
> Since the "invoke the event listeners" algorithm (step 4.7) doesn't say to
> do anything with exceptions, that means that nothing must be done with them,
> eg. discard them.  (Anne: correct?)  Maybe this could use a note, though.

It should reach window.onerror. Allan introduced new language
constructs in ES6 for this. I'm hoping that WebIDL/JSIDL will adopt
these and make them available to platform APIs (or platform APIs
should reference them directly, however we end up resolving that).
Then it should all be a bit clearer which exceptions propagate and
which are only for window.onerror.


--
http://annevankesteren.nl/

Reply | Threaded
Open this post in threaded view
|

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

Glenn Maynard
In reply to this post by johnjbarton
On Mon, Jun 3, 2013 at 9:25 AM, John Barton <[hidden email]> wrote:
Thanks for pointing to the correct document. However, I'm confused. I could not find any thing on how exceptions are handled when dispatchEvent is called from JS.  Exception handling is discussed for Futures.

As currently implemented in Chrome and Firefox, dispatchEvent() acts like a JS function call -- it does not create an event-loop turn and like a host event -- it fails to propagate the exceptions.  This combination feels like an accident, not an intended behavior. 

As Anne says, errors should be sent to global error handling, but they definitely shouldn't cause the event dispatch to be aborted and prevent other event handlers from being run.  I'm not sure if you mean the first part of that or the last, but it's definitely intentional that a failed event handler won't prevent other event handlers from running.  That would probably break large portions of the web.

Surely you don't mean that the exception should be discarded just because the spec says nothing?

Specs say what to do--they don't enumerate every single thing not to do.  That said, this is probably currently underspecified; Anne described where the fix will probably be (eg. somewhere in WebIDL).

--
Glenn Maynard

Reply | Threaded
Open this post in threaded view
|

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

Anne van Kesteren-4
In reply to this post by Anne van Kesteren-4
On Mon, Jun 3, 2013 at 3:49 PM, John Barton <[hidden email]> wrote:
> Sorry I intended to reply all, but failed. Can we move this back to the
> group?

Okay, done.


> On Mon, Jun 3, 2013 at 7:40 AM, Anne van Kesteren <[hidden email]> wrote:
>> The callback is invoked in its own JS stack iirc. Agreed that the
>> language needs to be made clearer in due course.
>
> Yes, the listener is called on a JS stack where it appears to have no JS
> caller. However this is not the same as an asynchronous event turn. The JS
> caller of dispatchEvent() is blocked, the listener is called on its own new
> stack, the exception occurs, the new stack unwinds, the exception is queue
> for printing, and then finally the JS caller of dispatchEvent() is
> unblocked; somewhere in there the exception is printed.

Yes, it'll reach window.error.


> The JS event-loop is a critical feature of the system and this kind of
> behavior is confusing.

It does not seem too confusing to me for event callback exceptions to
never propagate up to dispatchEvent(), especially given they execute
in their own context. We can't modify this either I think, though
you're welcome to try in Chrome and report back.


--
http://annevankesteren.nl/

Reply | Threaded
Open this post in threaded view
|

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

Anne van Kesteren-4
On Mon, Jun 3, 2013 at 4:18 PM, John Barton <[hidden email]> wrote:
> The confusing is the timing. dispatchEvent() acts in some ways as if it is
> asynchronous -- errors do not propagate -- and in other ways as if it is --
> the timing of the call is nested within the caller.  Simply queuing the
> event for execution on the next turn would make the platform more
> consistent.

I'm not convinced, but lets say you're correct, what's the next step?


--
http://annevankesteren.nl/

Reply | Threaded
Open this post in threaded view
|

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

Jonas Sicking-2

I think it would be great if dispatchEvent dispatched the event at end-of-microtask or some such. Mainly to avoid reentrancy issues for web authors. And returned a Future<boolean> to indicate if default action should be run.

But there is absolutely no way that that is compatible with existing content.

Best we can do is to introduce a new dispatch function that works that way.

/ Jonas

On Jun 3, 2013 10:46 AM, "Anne van Kesteren" <[hidden email]> wrote:
On Mon, Jun 3, 2013 at 4:18 PM, John Barton <[hidden email]> wrote:
> The confusing is the timing. dispatchEvent() acts in some ways as if it is
> asynchronous -- errors do not propagate -- and in other ways as if it is --
> the timing of the call is nested within the caller.  Simply queuing the
> event for execution on the next turn would make the platform more
> consistent.

I'm not convinced, but lets say you're correct, what's the next step?


--
http://annevankesteren.nl/

Reply | Threaded
Open this post in threaded view
|

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

Glenn Maynard
In reply to this post by Glenn Maynard
On Mon, Jun 3, 2013 at 10:14 AM, John Barton <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

John Barton



On Mon, Jun 3, 2013 at 3:36 PM, Glenn Maynard <[hidden email]> wrote:
On Mon, Jun 3, 2013 at 10:14 AM, John Barton <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Glenn Maynard
On Mon, Jun 3, 2013 at 6:33 PM, John Barton <[hidden email]> 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.
 
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.

Making APIs asynchronous makes them much more cumbersome to use.  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

Reply | Threaded
Open this post in threaded view
|

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

John Barton



On Mon, Jun 3, 2013 at 5:09 PM, Glenn Maynard <[hidden email]> wrote:
On Mon, Jun 3, 2013 at 6:33 PM, John Barton <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

Glenn Maynard
On Mon, Jun 3, 2013 at 7:36 PM, John Barton <[hidden email]> 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.

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

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

--
Glenn Maynard

Reply | Threaded
Open this post in threaded view
|

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

John Barton



On Mon, Jun 3, 2013 at 6:00 PM, Glenn Maynard <[hidden email]> wrote:
On Mon, Jun 3, 2013 at 7:36 PM, John Barton <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

Boris Zbarsky
On 6/3/13 11:48 PM, John Barton wrote:
> 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.

It's primary job is to dispatch the event and run all the handlers.

> (We don't need dispatchEvent(), we could call the
> handlers directly if we want, so why don't we?

Because you can't in fact call them all directly: there is no way to get
the list of all handlers, and you didn't necessarily register them all.
  For one thing, often some of the handlers are registered by the UA
itself (sometimes as capturing listeners, sometimes as default actions).

> That primary job got compromised when the
> the fundamentally asynchronous mission was shoe horned in to a
> synchronous call with a return value.

You mean at the moment the API was initially added, right?

You may well be right that at the time it would have been better to
design it the way you suggest, with the dispatch happening async.  It
sure would have made a lot of things easier in the implementation of a
UA.  But that didn't happen, and content very much depends on the
current behavior....

So if you want a different behavior, you need a different API.  Except
of course the "easier implementation" argument no longer applies.

-Boris

Reply | Threaded
Open this post in threaded view
|

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

Glenn Maynard
In reply to this post by John Barton
On Mon, Jun 3, 2013 at 10:48 PM, John Barton <[hidden email]> wrote:
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).

dispatchEvent's job is to dispatch events.  Queueing isn't part of its job.  dispatchEvent is the JavaScript analog to saying "dispatch an event" or "fire an event" in specs, and when you say "fire an event named foo" in a spec, that doesn't queue a task.  When a spec wants that, it wraps it in a task, eg. "queue a task to fire an event", and that's very often not wanted.

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.

On the contrary, event dispatch is fundamentally synchronous.  It's sometimes nested in an asynchronous algorithm, but event dispatch doesn't care about that.

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.

Using the event loop system just to change the way an exception is handled doesn't make any sense to me.  (Also, here you seem to be suggesting that each listener should be its own task on the event queue.  That would mean other tasks would be allowed to run between listeners on the same event, which would be very bad.)

--
Glenn Maynard

Reply | Threaded
Open this post in threaded view
|

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

Domenic Denicola
From: Glenn Maynard [[hidden email]]

> Using the event loop system just to change the way an exception is handled doesn't make any sense to me.

Really? To JavaScript programmers, it's the only thing that makes sense. There is no way in native JavaScript semantics to do the magic thing the web platform currently does, wherein (a) code is executed synchronously, but (b) exceptions thrown from that code bypass any surrounding `try`/`catch` blocks, and instead reach `window.onerror`.

>From the perspective of reducing magic in the platform, and providing basic primitives JavaScript programmers can use to polyfill and prollyfill future extensions to the platform, John's objection makes perfect sense. There is black C++ magic going on inside dispatchEvent, and it's unfortunate and surprising to JavaScript programmers.

We can't change it, for legacy reasons. But maybe we could expose that black magic to the platform for developers to use, so that it becomes less magic and more technology, that would allow us to build faithful `dispatchEvent` polyfills.

Reply | Threaded
Open this post in threaded view
|

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

Boris Zbarsky
On 6/4/13 11:19 AM, Domenic Denicola wrote:
>> Using the event loop system just to change the way an exception is handled doesn't make any sense to me.
>
> Really? To JavaScript programmers, it's the only thing that makes sense. There is no way in native JavaScript semantics to do the magic thing the web platform currently does, wherein (a) code is executed synchronously, but (b) exceptions thrown from that code bypass any surrounding `try`/`catch` blocks, and instead reach `window.onerror`.

Uh... Sure there is.  It's as simple as a function that catches the
exception and then calls window.onerror, no?

-Boris

Reply | Threaded
Open this post in threaded view
|

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

Domenic Denicola
From: Boris Zbarsky [[hidden email]]

> Uh... Sure there is.  It's as simple as a function that catches the exception and then calls window.onerror, no?

My impression was that `window.onerror` had a lot of special semantics behind it, e.g. censoring cross-domain stack traces on `Error` objects, determining the error message/URL/line number combination (sometimes), dealing with the return value of onerror, etc. See http://www.w3.org/html/wg/drafts/html/master/webappapis.html#runtime-script-errors and related.

Reply | Threaded
Open this post in threaded view
|

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

Bjoern Hoehrmann
In reply to this post by Boris Zbarsky
* Boris Zbarsky wrote:
>On 6/4/13 11:19 AM, Domenic Denicola wrote:
>> Really? To JavaScript programmers, it's the only thing that makes sense.
>> There is no way in native JavaScript semantics to do the magic thing the
>> web platform currently does, wherein (a) code is executed synchronously,
>> but (b) exceptions thrown from that code bypass any surrounding
>> `try`/`catch` blocks, and instead reach `window.onerror`.
>
>Uh... Sure there is.  It's as simple as a function that catches the
>exception and then calls window.onerror, no?

That may end up having different behavior when it comes to stack traces
and debugger behavior.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

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

Boris Zbarsky
In reply to this post by Domenic Denicola
On 6/4/13 2:00 PM, Domenic Denicola wrote:
> From: Boris Zbarsky [[hidden email]]
>
>> Uh... Sure there is.  It's as simple as a function that catches the exception and then calls window.onerror, no?
>
> My impression was that `window.onerror` had a lot of special semantics behind it, e.g. censoring cross-domain stack traces on `Error` objects

If you caught the exception, then either you can get the stack trace
from it or not.  In either case, it's obviously safe to pass whatever
you have to window.onerror.

But in any case, window.onerror does not get a stack trace.  It does get
other information which you can either get from the exception or not
(and if you can, then there is no reason to censor it from onerror).

> determining the error message/URL/line number combination (sometimes)

See above.

> dealing with the return value of onerror

That just affects whether the exception is reported to the browser's
error console.  You're right that such reporting is not currently
possible in the web platform; that's the only piece of this stuff that
seems to be missing.

> See http://www.w3.org/html/wg/drafts/html/master/webappapis.html#runtime-script-errors

Yes, I'm quite familiar with that part of the spec, and at least one of
its implementations.  ;)

-Boris

12