[whatwg] Error propagation in child workers

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

Received on Tuesday, 16 December 2008 15:08:16 UTC