W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2008

[whatwg] Error propagation in child workers

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 23 Dec 2008 21:10:34 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0812232107200.24109@hixie.dreamhostps.com>
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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 23 December 2008 13:10:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:46 UTC