On Wed, Dec 24, 2008 at 12:51 AM, Ian Hickson <[email protected]> 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
