[Bug 12067] New: Improve error handling in workers

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12067

           Summary: Improve error handling in workers
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Web Workers (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: jonas@sicking.cc
         QAContact: member-webapi-cvs@w3.org
                CC: mike@w3.org, public-webapps@w3.org


The error handling for workers is currently somewhat lacking. Consider a
scenario when window A creates dedicated worker B which creates dedicated
worker C. Currently if an error occurs in C, the following error handling
occurs:

1. Fire "error" event on the global object for worker C.
2. Fire "error" event on the worker object associated with C.
3. Fire "error" event on the worker object associated with B.
(and so on for each "parent" dedicated worker)
4. Report error to the user.

If at any point an error is canceled (by calling event.preventDefault while the
event is being fired), the steps are aborted an no new events are fired.

There are two, related, problems here:

First off window.onerror isn't involved. This generally works as a choke point
to catch any programming errors, but currently doesn't catch errors in workers.
Instead developers are required to add a event listener to every worker created
and have that listener forward the errors to whatever code handles
window.onerror.

The second problem is that the same problem occurs within a worker. I.e. if a
worker creates several workers, and want to catch all errors occurring within
itself or its "sub workers", it needs to both listen to globalscope.onerror as
well as the error event on any and all workers it creates.


To fix this, I suggest the following error propagation:

1. Fire "error" event on the global object for worker C.
2. Fire "error" event on the worker object associated with C.
3. Fire "error" event on the global object for worker B.
4. Fire "error" event on the worker object associated with B.
(and so on for each "parent" dedicated worker)
5. Fire "error" event on window A.
6. Report error to the user.

As before, if an error is cancelled, the steps are aborted and no further
events are fired.

This allows any worker to discover, and handle, programming errors within
itself by simply listening to the error events on its scope. It also allows
catching all unhandled programming errors in the context of a page by simply
listening to window.onerror.

This is what we have implemented in firefox for as long as we've had workers,
so it's unlikely to break the world.


For shared workers, the propagation should stop after firing the "error" event
on the global object for the shared worker. This is similar to how error
handling works on shared workers today.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Monday, 14 February 2011 22:11:00 UTC