Gecko:ErrorMessages

DOM Scripting Error Messages

bug 329026

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

1. Add XXX ERRMSG comments at relevant code points where an error should be reported ... either as we find them, or by auditing content/ code
2. Define a concise, efficient, expressive API for reporting errors (in a localizable way?), with parameters
3. 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. But as written here, it's not safe ... a bad translation could cause a crash. How important is localizability? What about the other parameters that ReportToConsole requires, can we avoid them like I want to here, or not?

I think the following parameters of ReportToConsole could be easily inferred from the fact that we're reporting a DOM error or possibly from the JS stack: aFile, aURI, aSourceLine, aLineNumber, aColumnNumber, aErrorFlags, aCategory. That includes the parameters that we'd just leave blanks (aSourceLine is a good example). That still leaves aMessageName, aParams, aParamsLength -- those are needed for localization. If we're willing to forgo params, we could just have a single arg; but at that point it might be better to just define new DOM error codes and make domerr.msg localizable or something. --Bzbarsky 16:40, 1 Mar 2006 (PST)