http://mxr.mozilla.org/mozilla/source/netwerk/test/httpserver/httpd.js#469 throw Cr.NS_ERROR_INVALID_ARG; causes the error message to be: Error: uncaught exception: 2147942487 At the very least the line out to read: throw "Cr.NS_ERROR_INVALID_ARG"; better would be: if (path.charAt(0) != "/") throw new Error("nsIHttpServer.registerDirectory path must start with '/': "+path); if (path.charAt(path.length - 1) != "/") throw new Error("nsIHttpServer.registerDirectory path must end with '/': "+path); if (directory && !directory.exists()) throw new Error("nsIHttpServer.registerDirectory directory does not exist "+(directory?directory.path:"directory argument undefined") ); if (!directory.isDirectory()) throw new Error("nsIHttpServer.registerDirectory path is not a directory "+directory.path );

With the code above the error message reads: nsIHttpServer.registerDirectory directory does not exist F:\bartonjj\projects\fireclipse\firebug\firebug\tests\content\firebugtests.xul

I don't think better error messages are needed here; what's needed is clearer attention to the existing documentation for the method in the sibling nsIHttpServer.idl file. Knowledge of which method call caused the exception, combined with the documentation for that method as given in that file, is sufficient to determine a solution to the problem you hit (perhaps with some dumping of pertinent details in your code before calling the method, but that's not httpd.js's responsibility). Please read the available documentation to see if errors you encounter are described before complaining that there isn't a good error message; documentation is just as valid a way to aid in debugging errors as more descriptive errors are. Outside of those concerns, note that we're intentionally implementing an XPCOM API so that the server can be used as a component, and we actually can't throw a more descriptive error. Further, I will not spew error messages to the console or elsewhere when the documentation adequately describes the particular error that's happened.

I am asking you to reconsider. I think that your core argument, that error messages are not needed because developers should not call functions with incorrect arguments, is ridiculous. But for the sake of progress I won't even ask that this be a basis for reconsidering this bug. Rather, I ask you to suggest a procedure, known to typical developers, to go from an error console message of: 2147942487 to the file nsIHttpServer.idl where they could try to figure out the problem. I believe the only procedure is the one I applied: I had to insert tracing messages over and over again until I narrowed down the source of the error message to the httpd.js call, then I read the source. Even then I had to figure out which of the 5 ways this message can be triggered. If the error message had the name of the component that would be a huge advantage. With the name of the method I might have even read the fabulous documentation. By adding the cause of the error, which the httpd.js code had already taken the trouble to determine, I could have fixed our code in two minutes rather than wasting two hours on it. As for spewing error messages, I am not asking for more messages, I am only asking that the message you already spew provide some information about where the error occurred.

This seems to boil down to the problem that, in pure JS, throwing a literal number or string results in an utterly useless exception object (i.e. it's just the literal), where as throwing new Error("foo") gives you all the source information automatically in addition to the "foo". I can only think of two good ways this could be resolved: - Thrown JS literals get the source information added forcibly. - XPCOM learns how to decode the exception from "throw new Error(Cr.NS_ERROR_INVALID_ARG)" into a normal XPCOM error code for C++ callers and httpd.js and co. are updated to use that.

(In reply to comment #3) > I think that your core argument, that error messages are not needed because > developers should not call functions with incorrect arguments, is ridiculous. That's not quite my argument, it's that error messages are not *necessary* when documentation of the errors is present, just to be clear. > Rather, I ask you to suggest a procedure, known to typical developers, to go > from an error console message of: > 2147942487 > to the file nsIHttpServer.idl where they could try to figure out the problem. > I believe the only procedure is the one I applied: I had to insert tracing > messages over and over again until I narrowed down the source of the error > message to the httpd.js call, then I read the source. Even then I had to > figure out which of the 5 ways this message can be triggered. I see nothing fundamentally wrong with this procedure up until the point where you read the source. Once you got to that point you should have used a lookup service to determine its name, like perhaps this one: http://silver.warwickcompsoc.co.uk/mozilla/misc/nserror?0x80070057 Then you should have compared the name to the ones listed in docs and double-checked that you weren't hitting any of the cases where the exception is specified to be thrown. I agree we should do a better job of documenting error codes so that they can be easily converted from numbers to names, but that's not a problem with the server. Think of it a different way: suppose your code were C++, and suppose the server were C++. Is there any way you could have gotten more information in the error in that situation than you did here? Fundamentally it does come down to XPCOM errors being opaque numbers whose meanings are not self-describing, and that's just the situation we have to live with.