- From: <bugzilla@jessica.w3.org>
- Date: Mon, 14 Feb 2011 22:10:58 +0000
- To: public-webapps@w3.org
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