[whatwg] Error propagation in child workers

[ben turner]

I'm implementing these latest changes and it looks like there are some
typos in this edit:

- The ErrorEvent interface has a 'fileno' property, not a 'lineno'
property as mentioned elsewhere. I believe it should be 'lineno'.

- There's a stray 'span>' before 'queue a task'.

Then I have a few more observations and questions:

1. The part about the initial value of onerror being undefined... I
understand why you'd want that, but we don't have a similar
requirement for onmessage. Should we?

2. Should we allow multiple error handlers in the scope via
addEventListener? Or should there only ever be one?

3. Currently the mozilla implementation also uses the error event
mechanism for parse errors in the worker script, and these errors will
be impossible to trap in the scope's onerror handler. I don't really
care about that but I wanted to mention it in case someone else does.

-Ben

On Wed, Dec 24, 2008 at 7:25 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Wed, Dec 24, 2008 at 12:51 AM, Ian Hickson <ian at hixie.ch> wrote:
>> On Tue, 23 Dec 2008, Jonas Sicking wrote:
>>> >
>>> > 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).
>>
>> Having the error be first reported outside of the context that created the
>> error seems really weird. window.onerror is a very widely used feature, I
>> don't see why it wouldn't be equally widely used in workers.
>
> If window.onerror really is popular despite the fact that try/catch
> now exists (it didn't when window.onerror was originally created) then
> I'm fine either way.
>
> / Jonas
>