[whatwg] Error propagation in child workers

On Tue, Dec 23, 2008 at 4:10 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 16 Dec 2008, Jonas Sicking wrote:
>> Ian Hickson wrote:
>> > On Thu, 27 Nov 2008, ben turner wrote:
>> > >
>> > > 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 ended up using a combination of both the event mechanism and the old
> Window.onerror mechanism. The spec now says to fire onerror in the worker
> global scope, using the old mechanism, and if that doesn't handle the
> error then a series of events going up the chain to the browsing context
> is fired until one is canceled.

What is the advantage of this? Seems like this is just re-inventing
try-catch. (yes, the same question can be posed for window.onerror,
but at least there there are legacy reasons).

/ Jonas

Received on Tuesday, 23 December 2008 14:07:15 UTC