873070 - WorkerErrorEvent should give more information about the original error

Status: RESOLVED INVALID

(Core :: DOM: Workers, defect)

Description

[David Teller [:Yoric] - still alive but not very active]

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).

Comment 1

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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.

Comment 2

[David Teller [:Yoric] - still alive but not very active]

(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.

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

(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 [e-mail] mailing list as well.

Comment 4

[David Teller [:Yoric] - still alive but not very active]

Given that I live platform-side, I can survive as long as necessary with mozExceptionConstructorName and mozStackInfo :)

Comment 5

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

Comment 7

[Boris Zbarsky [:bzbarsky]]

Unless the suggestion is that we add [ChromeOnly] bits here?

Comment 9

[David Teller [:Yoric] - still alive but not very active]

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)