W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 04 Jun 2013 14:04:13 -0400
Message-ID: <51AE2C1D.7030906@mit.edu>
To: Domenic Denicola <domenic@domenicdenicola.com>
CC: "www-dom@w3.org" <www-dom@w3.org>
On 6/4/13 2:00 PM, Domenic Denicola wrote:
> From: Boris Zbarsky [bzbarsky@MIT.EDU]
>
>> 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
Received on Tuesday, 4 June 2013 18:04:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC