Re: [whatwg] Error propagation in child workers
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 jo...@sicking.cc wrote: On Wed, Dec 24, 2008 at 12:51 AM, Ian Hickson i...@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
Re: [whatwg] Error propagation in child workers
On Sat, 27 Dec 2008, ben turner wrote: 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'. Oops. Fixed. Thanks. 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? Historically, onerror is the only attribute that acts like this on Window. I agree that it is kind of weird, but I think we're better off just leaving it like that -- weirdness is bad enough, but inconsistent weirdness is even worse. 2. Should we allow multiple error handlers in the scope via addEventListener? Or should there only ever be one? How does it work with Window error reporting? 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. I think that's ok. Workers are equivalent to script blocks with a single script, and the same limitation applies there. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Error propagation in child workers
On Wed, Dec 24, 2008 at 12:51 AM, Ian Hickson i...@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
Re: [whatwg] Error propagation in child workers
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Error propagation in child workers
On Tue, Dec 23, 2008 at 4:10 PM, Ian Hickson i...@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
Re: [whatwg] Error propagation in child workers
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 jo...@sicking.cc wrote:
On Tue, Dec 23, 2008 at 4:10 PM, Ian Hickson i...@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
Re: [whatwg] Error propagation in child workers
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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Error propagation in child workers
On Thu, 27 Nov 2008, ben turner wrote:
I just got around to fixing the error handling in our worker
implementation and realized that the spec is a little vague here,
especially when workers are created within workers. This is what we have
now, and Jonas and I both find it intuitive and useful:
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.
For shared workers, we could either support this in the same way, or
always report the errors to the console and not have a way to catch them.
Or, we could not have any ways to catch these unhandled exceptions at all.
I'm interested in feedback from other implementors here -- is this
something you are interested in?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Error propagation in child workers
Ian Hickson wrote:
On Thu, 27 Nov 2008, ben turner wrote:
I just got around to fixing the error handling in our worker
implementation and realized that the spec is a little vague here,
especially when workers are created within workers. This is what we have
now, and Jonas and I both find it intuitive and useful:
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.e. that if the main window creates worker A, which creates a child
worker B, and an error happens in B, then the following should happen:
1. A should be first given a chance to handle the error using B.onerror
2. If A doesn't handle the error the error is forwarded to the main
window by calling A.onerror
3. If the main window doesn't handle the error, the error gets reported
to any developer-error-console mechanism that the UA has (if any).
/ Jonas
[whatwg] Error propagation in child workers
Hey folks,
I just got around to fixing the error handling in our worker
implementation and realized that the spec is a little vague here,
especially when workers are created within workers. This is what we
have now, and Jonas and I both find it intuitive and useful:
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;
}
If the child worker experiences an unhandled exception, syntax error,
etc., then an 'error' event is fired at the child worker that will run
in the parent's execution scope. If the parent has an error handler it
will be called, and the handler can call 'event.preventDefault()' to
stop propagation. Otherwise another error event will be dispatched to
the parent's parent, etc., until we reach the top-level worker. And
finally, for Firefox at least, we plan to log an error message in the
JS console if the top-level worker doesn't have a handler and call
preventDefault (as we've found that the lack of error logging is a
common development headache).
So, what do you guys think?
-Ben Turner
