I'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.)

Won'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.