While I was in the midst of developing a new add-on for Firefox, I ran across the need to do some error handling while using an XPCOM interface. By using a try...catch block in my Javascript code, I was able to capture the exceptions thrown by the XPCOM component. If you have used Firefox's Error Console, you probably have already seen what one of these exceptions look like:
The exception produces a result code that begins with the letters NS, which is called an nsresult. I was able to find ample information on nsresults at MDC and elsewhere, but I couldn't find documentation anywhere about how to determine the result code from Javascript in order to effectively handle the error. By iterating over the properties and methods of the error object produced in Javascript, I was able to come up with the following information:
Methods
QueryInterface()
initialize()
Properties
message
[string] Full description of the error.
result
[integer] A number (always 10-digits?).
name
[string] The nsresult code (ex. NS_ERROR_FAILURE).
filename
[string] URI of the Javascript file in which the error occurred (chrome://...).
lineNumber
[integer] Line number of the Javascript file on which the error occurred.
columnNumber
[integer] Column number of the Javascript file on which the error occurred (usually 0?).
location
[string] Summary of where in chrome the error occurred (ex. JS frame :: chrome://... :: anonymous :: line 77).
inner
[null] ? Came up as null in my test; no idea what it might be used for.
data
[null] ? If it's not null, my guess is that it would contain extra information produced by the exception or passed to/from it.
Knowing this, we can now handle the exception in Javascript like so:
/* supposing that the variable "file" is an nsIFile object,
this example uses the "remove" method of nsIFile */
try {
file.remove(false);
} catch (e) {
switch (e.name) { // use the "name" property to get the nsresult
case 'NS_ERROR_FILE_TARGET_DOES_NOT_EXIST':
// error handling code goes here
break;
case 'NS_ERROR_FILE_DIR_NOT_EMPTY':
// error handling code goes here
break;
case 'NS_ERROR_FILE_ACCESS_DENIED':
// error handling code goes here
break;
default:
// if necessary, include handling of all other errors here
}
}
I hope this information helps other add-on developers who are working with XPCOM.
Further information and reference:
