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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
