- From: ben turner <bent.mozilla@gmail.com>
- Date: Thu, 27 Nov 2008 01:10:56 -0500
Hey folks, I just got around to fixing the error handling in our worker implementation and realized that the spec is a little vague here, especially when workers are created within workers. This is what we have now, and Jonas and I both find it intuitive and useful: Assuming we have a page that creates a worker (let's call this worker the parent), and it creates a new worker (the child). First, we currently use a MessageEvent object for our 'error' events where the 'data' property contains a string representing the exception, but we don't really like that. We'd like to propose that we use a new type of event, ErrorEvent, that looks like this: interface ErrorEvent : Event { readonly attribute DOMString message; readonly attribute DOMString filename; readonly attribute unsigned long lineno; } If the child worker experiences an unhandled exception, syntax error, etc., then an 'error' event is fired at the child worker that will run in the parent's execution scope. If the parent has an error handler it will be called, and the handler can call 'event.preventDefault()' to stop propagation. Otherwise another error event will be dispatched to the parent's parent, etc., until we reach the top-level worker. And finally, for Firefox at least, we plan to log an error message in the JS console if the top-level worker doesn't have a handler and call preventDefault (as we've found that the lack of error logging is a common development headache). So, what do you guys think? -Ben Turner
Received on Wednesday, 26 November 2008 22:10:56 UTC