Ian Hickson wrote:
On Thu, 27 Nov 2008, ben turner wrote:
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;
}
How do you feel instead about using the same mechanism on Worker objects
as we currently use on Window for error handling?
Specifically, window.onerror is called as a function with three arguments
when an error occurs. I'm suggesting that when a worker has an unhandled
exception, we fire Worker.onerror outside the worker, again with three
arguments (message, script url, line number). If the function return
false, then the error reporting is quenched; otherwise, it is reported in
the warning console.
I talked with Ben about this. We don't really feel strongly either way,
so changing it is fine. That said, we already have the other behavior
implemented so unless anyone feels strongly I suggest we keep it. I do
agree there would be more consistency with window.onerror if we went the
other way, but there would be less consistency with the other Worker.on*.
In any case, I do think that the "bubbling" mechanism should remain.
I.e. that if the main window creates worker A, which creates a child
worker B, and an error happens in B, then the following should happen:
1. A should be first given a chance to handle the error using B.onerror
2. If A doesn't handle the error the error is forwarded to the main
window by calling A.onerror
3. If the main window doesn't handle the error, the error gets reported
to any developer-error-console mechanism that the UA has (if any).
/ Jonas
