637307 - nsIErrorService.getErrorStringBundleKey() throws NS_ERROR_OUT_OF_MEMORY

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Dennis de Klerk]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110224 Firefox/4.0b13pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15pre) Gecko/20110224 Ubuntu/10.10 (maverick) Namoroka/3.6.15pre

Open error console and eval:
>> Components.classes["@mozilla.org/xpcom/error-service;1"].getService(Components.interfaces.nsIErrorService).getErrorStringBundleKey(Components.results.NS_ERROR_FILE_NOT_FOUND)

Or any other valid NS_ERROR_* value.

And you get:

Error: uncaught exception: [Exception... "Component returned failure code: 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [nsIErrorService.getErrorStringBundleKey]"  nsresult: "0x8007000e (NS_ERROR_OUT_OF_MEMORY)"  location: "JS frame :: javascript:%20Components.classes["@mozilla.org/xpcom/error-service;1"].getService(Components.interfaces.nsIErrorService).getErrorStringBundleKey(Components.results.NS_ERROR_FAILURE) :: <TOP_LEVEL> :: line 1"  data: no]

Happens on Firefox 3.6.15.pre, 4.0b13pre.
Happens when called from script (not from eval in console window) on --debug XULRunner app build from current (week old) mozilla-central.

All I want is get a nice human readable string for file errors. 
Eg. NS_ERROR_FILE_NOT_FOUND = "File error: Not found"
As defined in http://mxr.mozilla.org/mozilla-central/source/js/src/xpconnect/src/xpc.msg


Reproducible: Always

Steps to Reproduce:
1. Open error console
2. eval Components.classes["@mozilla.org/xpcom/error-service;1"].getService(Components.interfaces.nsIErrorService).getErrorStringBundleKey(Components.results.NS_ERROR_FILE_NOT_FOUND)
Actual Results:  
Error: uncaught exception: [Exception... "Component returned failure code: 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [nsIErrorService.getErrorStringBundleKey]"  nsresult: "0x8007000e (NS_ERROR_OUT_OF_MEMORY)"  location: "JS frame :: javascript:%20Components.classes["@mozilla.org/xpcom/error-service;1"].getService(Components.interfaces.nsIErrorService).getErrorStringBundleKey(Components.results.NS_ERROR_FAILURE) :: <TOP_LEVEL> :: line 1"  data: no]

Expected Results:  
Return human readable error message

Comment 1

[Dennis de Klerk]

Usecase is i'm using nsIUnicharStreamLoaderObserver.onStreamComplete which receives an nsresult argument. I wish to translate that nsresult to a human readable string for display in an alert popup.

Comment 2

[Boris Zbarsky [:bzbarsky]]

This service can only handle errors that are registered with it.  And nothing registers anything with it as far as I can tell.  This is all dead code.

Comment 3

[ISHIKAWA, Chiaki]

I am trying to find out how to use nsIErrorService myself
to catch and print meaningful error message for Bug 
Bug 567585 "TB3 fails to raise an error when it tries to save an attachment to write-protected directory."
Actually, I have found out TB fails to produce meaningful error dialog for other I/O errors, too. So I want to print something useful using nsIErrorService.

But shouldn't we 
use the macro NS_ERROR_GET_CODE for the argument to getErrorStringBundleKey()?

eval Components.classes["@mozilla.org/xpcom/error-service;1"].getService(Components.interfaces.nsIErrorService).getErrorStringBundleKey(NS_ERROR_GET_CODE(Components.results.NS_ERROR_FILE_NOT_FOUND))

I am unsure of 
>*This service* can only handle errors that are registered with it.  And >nothing registers anything with it as far as I can tell.  This is all dead >code.

Are we talking about XPCOM in general (if so, bad!), or
nsIUnicharStreamLoaderObserver.onStreamComplete in particular?

Comment 4

[ISHIKAWA, Chiaki]

> But shouldn't we 
> use the macro NS_ERROR_GET_CODE for the argument to
> getErrorStringBundleKey()?

Well, I found out that only one javascript file seems to use
NS_ERROR_GET_MODULE() by defining an equivalent javascript function in it. (searched comm-central using 
http://mxr.mozilla.org/comm-central/ )

I defined NS_ERROR_GET_CODE() in my own javascript code patch,
and tried to search for a corresponding string.
As far as I can tell, I/O error codes could not be searched since as the original reporter reported,
the function returned OUT OF MEMORY error when the string bundle is not defined for the class of errors.
Touch luck :-(

Comment 5

[Kevin Locke]

If nsIErrorService is dead (as it appears), is there a supported/recommended way for implementers of nsIRequestObserver and similar interfaces in JavaScript to translate the nsresult status parameter to something useful for end users?

After a bit of poking around, nsXPCException::NameAndFormatForNSResult is the best I could find, but it is not directly exposed to JavaScript.  It is used by nsXPCException to populate the name and message for toString (but interestingly not for GetMessage), so I can get to it with the following horribly ugly hack:

var ex = Components.classes["@mozilla.org/js/xpc/Exception;1"]
    .createInstance(Components.interfaces.nsIXPCException);
ex.initialize(null, statusCode, null, null, null, null);
var [, message, name] = /^\[Exception... "(.*)"  nsresult: "0x[0-9a-fA-F]* \((.*)\)"  location: ".*"  data: .*\]$/.exec(ex.toString());

But it is obviously very brittle, so I'm hoping there is a better way.

Comment 6

[ISHIKAWA, Chiaki]

I think mozilla really  ought to have a robust error mapping (to human-readable string). This lack may explain why many error conditions are simply ignored: after all, if you can't explain what the error is to human users in a meaningful manner, it is not really useful to catch errors, and try to do something useful based on the error condition (for the users).

Comment 7

[ISHIKAWA, Chiaki]

It was argued that 
nsIErrorService is dead and I should simply not use it in proposed patch,
( https://bugzilla.mozilla.org/show_bug.cgi?id=567585#c85 )
and I was happy enough to follow the advise :-)

Seriously, maybe someone can cook up a more robust routine
along the line suggested by Kevin in comment 5 above?

TIA

Comment 8

[:Gijs (he/him)]

getErrorStringBundleKey no longer exists, removed in bug 978486.