A way of explicitly reporting exceptions

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Jun 23 13:35:02 PDT 2014


I personally don't think it's DOM responsibility to clean up after "your"
errors and I'd expect DOM to keep firing if a listener set by some other
library or scope I don't know/own fails, as it has always been.

The only improvement I could think of is some info reachable through the
event object, similar for `.isDefaultPrevented()` so that
`.hasUncaughtError()` will return true and it's still developer
responsibility to deal with such case when/if needed.

The most common Web scenario is where different libraries expect different
behaviors from same handlers set on elements shared and reachable globally
... I'd rather not interfere with a generic listener and handlers stack I
don't personally own from my code.

Last, but not least, I've seen only callback references in this topic, but
if something changes, please remember there are tons of libraries out there
that use the more handy EventListener#handleEvent() [1] call so context
should be considered too whatever change will be decided.

Best Regards

[1] http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener





On Mon, Jun 23, 2014 at 1:26 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 6/23/14, 4:25 PM, Boris Zbarsky wrote:
>
>> That's an interesting issue too.  Right now I believe browsers can
>> internally rethrow an exception without changing its stack trace...  But
>> there is no way for script to do that.
>>
>
> Actually, I might be wrong there if the stack trace is captured at the
> time the Error object is constructed.
>
>
> -Boris
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140623/1ebf2e71/attachment.html>


More information about the es-discuss mailing list