Closed Bug 873070 Opened 8 years ago Closed 5 years ago
Error Event should give more information about the original error
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 David Rajchenbach Teller [:Yoric] from comment #2) > That's what I had in mind. Ok, then that would need to be proposed to the email@example.com 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.
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
Unless the suggestion is that we add [ChromeOnly] bits here?
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)
You need to log in before you can comment on or make changes to this bug.