Closed Bug 873070 Opened 8 years ago Closed 5 years ago

WorkerErrorEvent should give more information about the original error

Categories

(Core :: DOM: Workers, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: Yoric, Unassigned)

References

Details

(Whiteboard: [Async:team])

WorkerErrorEvents are thrown whenever a JS error reaches the top level of a worker. Unfortunately, they are rather annoying to use.

e.g.
1. calling method |toString| produces an unhelpful string "[WorkerErrorEvent]";
2. it seems that there is no way to extract from a WorkerErrorEvent the kind of error that was originally thrown;
3. there doesn't seem to be a convenient way to extract from a WorkerErrorEvent the stack information.

It would be useful to extend WorkerErrorEvent to fix these issues. In particular, point 2. would be extremely useful to deal with asynchronous error handling (in a setting involving Task.jsm).
WorkerErrorEvents should have 'message', 'filename', and 'lineno' properties that explain the error... Maybe you're just unaware of those?

The original exception object cannot be exposed due to the fact that the error event represents an exception that happened in another JSRuntime.

Stack information is not available though I guess we could maybe serialize the stack somehow.
(In reply to ben turner [:bent] from comment #1)
> WorkerErrorEvents should have 'message', 'filename', and 'lineno' properties
> that explain the error... Maybe you're just unaware of those?

I am aware of these.

> The original exception object cannot be exposed due to the fact that the
> error event represents an exception that happened in another JSRuntime.

I realize that the exception object cannot be exposed in the current state of JavaScript. However, just the name of the exception constructor would be useful for filtering out by exception cause and/or rebuilding a "regular" exception object manually.

> Stack information is not available though I guess we could maybe serialize
> the stack somehow.

That's what I had in mind.
(In reply to David Rajchenbach Teller [:Yoric] from comment #2)
> That's what I had in mind.

Ok, then that would need to be proposed to the public-webapps@w3.org mailing list as well.
Given that I live platform-side, I can survive as long as necessary with mozExceptionConstructorName and mozStackInfo :)
Well, we're trying not to add any more prefixed things these days... The new plan is that any standardization-path features that are unique to Firefox should live behind a runtime flag.
Whiteboard: [Async] → [Async:team]
Marking invalid; we're following the spec here.  If you think the spec should be changed, please raise an actual spec issue at https://github.com/whatwg/html/issues
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
See Also: → 986459
Unless the suggestion is that we add [ChromeOnly] bits here?
Flags: needinfo?(dteller)
Duplicate of this bug: 986459
Yes, the idea was to make it [ChromeOnly], at least for the time being. And possibly raise a spec issue, but since I'm not using this piece of tech anymore, I'm probably not the best person to do it.

(sorry for the delay, I'm just back from long PTO)
Flags: needinfo?(dteller)
You need to log in before you can comment on or make changes to this bug.