Open
Bug 1280258
Opened 9 years ago
Updated 3 years ago
Add saner error reporting APIs
Categories
(Core :: JavaScript Engine, defect, P3)
Core
JavaScript Engine
Tracking
()
NEW
People
(Reporter: jandem, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: triage-deferred)
We have many lines like:
JS_ReportErrorNumber(cx, GetErrorMessage, nullptr, JSMSG_BAD_ARRAY_LENGTH);
A lot of boilerplate, but it doesn't tell us the exception type (RangeError in this case). It'd be really nice to replace this with just:
JS::ThrowRangeError(cx, JSMSG_BAD_ARRAY_LENGTH);
I think we can remove the error message callbacks somehow if we make JSMSG_BAD_ARRAY_LENGTH expand to something (pointer or struct) that stores the error number, error message, etc.
Comment 1•9 years ago
|
||
This is arguably a dup of bug 1063241, but having a clean bug for what's likely to be a bunch of fresh work (existing patchwork having bitrotted) probably isn't a bad idea. Much a fan of having JS::ThrowRangeError and similar, for sure, then.
Reporter | ||
Comment 2•9 years ago
|
||
Looking at this I noticed there's a problem with the js::GetErrorMessage call in xpc::ErrorReport::Init - because the embedding can supply its own *.msg files, multiple messages (say one in js.msg and one in jsshell.msg) can have the same error number.
Not sure yet what to do about that.
Reporter | ||
Comment 3•9 years ago
|
||
(In reply to Jan de Mooij [:jandem] from comment #2)
> Not sure yet what to do about that.
If we use the template class approach in bug 1063241, we can store the identifier we use for devtools/MDN in it - that way we can kill the error number completely.
Updated•8 years ago
|
Keywords: triage-deferred
Priority: -- → P3
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•