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

On Tue, Jun 4, 2013 at 10:19 AM, Domenic Denicola <
domenic@domenicdenicola.com> 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`.
>
> 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.
>

It doesn't make sense to this JavaScript programmer.  Making a whole
operation asynchronous just to do something different with an exception is
a weird hack.  That's what exception handlers are for.  This isn't anything
magic, there's just a try/catch block inside dispatchEvent, so of course
exceptions don't reach your higher-level exception handler.  That's how
exceptions work.

If calling onerror directly has problems, then adding a
runWithErrorHandling(callback) method makes a lot more sense than making
APIs asynchronous that don't need to be.

Note that you wouldn't want to call window.onerror directly, since you want
"error" event listeners to be run, too.  You'd dispatch an ErrorEvent, eg.
window.dispatchEvent(new ErrorEvent("error", {"message": "message",
filename: "filename", lineno: 100}));

On Tue, Jun 4, 2013 at 1:04 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

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


It's currently harder than it should be to get line number and filename
information out of exceptions, but that's a separate problem.  (Firefox has
fileName and lineNumber fields on exceptions, making this easy, but Chrome
doesn't.  I don't know if this is specced anywhere.)

See http://www.w3.org/html/wg/**drafts/html/master/webappapis.**
>> html#runtime-script-errors<http://www.w3.org/html/wg/drafts/html/master/webappapis.html#runtime-script-errors>
>
>
(ITYM
http://www.whatwg.org/specs/web-apps/current-work/#runtime-script-errors)

-- 
Glenn Maynard