W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2008

[whatwg] Error propagation in child workers

From: ben turner <bent.mozilla@gmail.com>
Date: Thu, 27 Nov 2008 01:10:56 -0500
Message-ID: <21b1517c0811262210y6c8db0e6j9198e1666169e81@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:07 UTC