[Bug 17713] Exceptions thrown from event handlers should not be propagated

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17713

--- Comment #16 from Boris Zbarsky <bzbarsky@mit.edu> ---
> I still disagree that you always want to swallow the exception from the
> callback. 

No one is talking about swallowing the exception.

The basic options for callback exceptions are catch-and-report and
catch-and-rethrow.  The latter is somewhat equivalent to "just abort and
pretend that you got an exception that interrupts whatever you're doing" maybe.

For APIs that call the callback directly off a task, of course,
catch-and-report is the only reasonable option.  In my opinion.  Note that for
these APIs it's often not equivalent to catch-and-rethrow, even if we define
that as reporting if there's no JS on stack (but of course interrupting
processing steps).

For what it's worth, the desired behavior of current standardized APIs that we
(Mozilla) have converted to WebIDL that use callbacks seems to be:

1) Promise: catch-and-do-something-complicated.
2) Window.setTimeout: catch-and-report (off a task, not equivalent to
   catch-and-rethrow).
3) EventHandler: catch-and-report.
4) EventListener: catch-and-report.
5) NodeFilter: catch-and-rethrow.
6) requestAnimationFrame: catch-and-report (off a task, not equivalent to
   catch-and-rethrow).
7) WebComponents: catch-and-report (haven't checked equivalence).
8) WebRTC success/error callbacks: catch-and-report (off a task, may be
   equivalent to catch-and-rethrow).
9) Notificaion.requestPermission: catch-and-report (off a task, equivalent to
   catch-and-rethrow).
10) System message callbacks: Can't tell, because I can't find where anyone
    invokes "fier a system message".
11) Mutation observers: catch-and-report.
12) Canvas.toBlob: catch-and-report (off a task, equivalent to
    catch-and-rethrow).
13) Geolocation: catch-and-report (off a task, equivalent to
catch-and-rethrow).
14) UndoManager: Processing model not defined enough for me to be able to tell.
15) AudioContext.decodeAudioData: catch-and-report (off a task, equivalent to
    catch-and-rethrow).

I believe that the specs for all of these say nothing about exceptions except
NodeFilter, which specifies the catch-and-rethrow behavior, and Promise which
specifies the complicated behavior it has.

Fundamentally, having the default behavior be catch-and-report means that spec
authors don't have to worry about calling a callback throwing an exception that
interrupts their processing model (as currently they seem not to).  Having the
default behavior be catch-and-rethrow means that any callback invocation needs
to explicitly consider the consequences of an exception...  There are pros and
cons to both.  :(

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Sunday, 4 August 2013 02:00:38 UTC