[whatwg] Error propagation in child workers

[ben turner]

Yes, I agree, try/catch works just as well for that. The only thing we
really need is a way to communicate errors to the parent IMO.

-Ben

On Tue, Dec 23, 2008 at 5:07 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> 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
>