Components.Exception on LXR
A long-standing custom in Mozilla code for XPCOM components in JavaScript is to throw Components.results.NS_ERROR_FAILURE or something like it. However, Components.Exception is more useful, particularly since it lets us component authors define our own error messages to go with the error code. Plus, it's been around for quite a while.
It's actually pretty useful, I've found. I'm wondering if we should add this to a list of to-do's for Mozilla 2.
Posted by WeirdAl at October 17, 2007 7:54 PMI've found Components.Exception to be unusable because it sets the error file and line number to its caller it instead of its caller's caller.
Or to say it in a understandable way:
Code in overlay.js calls a method of myComponent.js with an invalid argument, the component throws a NS_ERROR_INVALID_ARG that isn't caught anywhere.
When throwing Cr.NS_ERROR_INVALID_ARG, the Error Console points to overlay.js. When throwing a Components.Exception object, it will point to myComponent.js. And that's just plain stupid and makes debugging much harder than it should be.
(From Alex: How is this a problem? The nsIException object it returns has a location property, which is a nsIStackFrame, and every nsIStackFrame has a caller property which is another nsIStackFrame, or null when you hit the end of the stack.
Believe me when I say it's very helpful to know where and why it failed.)
Posted by: malte at October 18, 2007 6:45 AMWon't a big (internal) feature of Mozilla 2 be allowing exceptions in C++ code? Perhaps XPCOM should be rethought with exceptions in mind, so exceptions can cross XPCOM boundaries.
Without boundary-crossing exceptions, there will still be lots of error handling done the old way, by checking returned result codes. Always using the same way of handling errors would be a big improvement. The Mozilla code base currently looks like it can't make up it's mind about how errors should be dealt with.
Posted by: James Justin Harrell at October 18, 2007 9:31 AM