Gecko:ErrorMessages: Difference between revisions
No edit summary |
|||
| Line 4: | Line 4: | ||
Adding better error messages doesn't seem like a very hard problem, it's just a considerable amount of drudge work (and perhaps, has to be done carefully to avoid bloat). | Adding better error messages doesn't seem like a very hard problem, it's just a considerable amount of drudge work (and perhaps, has to be done carefully to avoid bloat). | ||
== Steps == | |||
# Add XXX ERRMSG comments at relevant code points where an error should be reported ... either as we find them, or by auditing content/ code | |||
# Define a concise, efficient, expressive API for reporting errors (in a localizable way?), with parameters | |||
# Figure out the wording of error messages at the ERRMSG points and implement the messages | |||
API something like this? | |||
<pre> | |||
nsContentUtils: | |||
static void ReportDOMError(nsISupports* aRelevantObject, const char* aMsg, | |||
...); | |||
nsHTMLCanvasElement::SetHeight(PRInt32 aHeight) { | |||
if (aHeight < 0) { | |||
nsContentUtils::ReportDOMError(this, "domerror.negative.height", height); | |||
return NS_ERROR_FAILURE; | |||
} | |||
</pre> | |||
The API would get the nearest JS source/line combination from the JS context stack, if available. | |||
Supporting varargs parameters seems like it would be useful. How important is localizability? | |||
Revision as of 10:30, 1 March 2006
DOM Scripting Error Messages
DOM scripting error messages are currently really bad for Web developers. Much of the time when something goes wrong during script execution, there's no feedback other than a JS exception with pretty much no information about what went wrong. Debugging the error is an exercise in guesswork and testing. We could do much better; many of our codepaths that just return NS_ERROR_FAILURE actually know at that point what the real error is.
Adding better error messages doesn't seem like a very hard problem, it's just a considerable amount of drudge work (and perhaps, has to be done carefully to avoid bloat).
Steps
- Add XXX ERRMSG comments at relevant code points where an error should be reported ... either as we find them, or by auditing content/ code
- Define a concise, efficient, expressive API for reporting errors (in a localizable way?), with parameters
- Figure out the wording of error messages at the ERRMSG points and implement the messages
API something like this?
nsContentUtils:
static void ReportDOMError(nsISupports* aRelevantObject, const char* aMsg,
...);
nsHTMLCanvasElement::SetHeight(PRInt32 aHeight) {
if (aHeight < 0) {
nsContentUtils::ReportDOMError(this, "domerror.negative.height", height);
return NS_ERROR_FAILURE;
}
The API would get the nearest JS source/line combination from the JS context stack, if available.
Supporting varargs parameters seems like it would be useful. How important is localizability?