12466 - xpconnect: catch errors that aren't strings

Status: VERIFIED FIXED

(Core :: XPConnect, defect, P3)

Description

[cbegle]

so i have an xpcom object that implements a method that looks like this:

NS_IMETHODIMP xpcTestCallJS :: Evaluate ( const char *s ) {
	if (jsobject)
		return jsobject->Evaluate(s);
	return NS_OK;
};

and a js object (the jsobject in the code above) that implements Evaluate like
this:
js> j.Evaluate = new Function("s", "print('evaluating '+s); return (eval(s))" );

if s contains a throw statement, an xpconnect exception does not get thrown
unless the throw argument is a string.

js> function TryIt( s ) {  try { o.Evaluate(s);} catch(e) { print(e); } }
js> // throwing a string -> xpc exception
js> TryIt("throw 'boo'")
evaluating throw 'boo'
[Exception... "boo [nsIXPCTestCallJS::Evaluate]"  nsresult: "0x8057001e (NS_ERRO
R_XPC_JS_THREW_STRING)"  location: "native frame :: <unknown filename> :: <TOP_L
EVEL> :: line 0"  data: no]

// throwing a number or object -> no exception thrown
js> TryIt("throw 1")
evaluating throw 1
js> TryIt( "throw {message:'An Errror Message'}" )
evaluating throw {message:'An Errror Message'}

it would be nice if you could throw an object that has information about the
exception. maybe even use the properties of the xpc excpetion object - data,
codes, etc ?

Comment 1

[John Bandhauer]

It is intentional that 'throw 1' not be considered and error. Throwing a number
is a way that JS code can signal 'return specific result code'. Codes < 0 are
errors and that works. Results are >= 0 are success codes. These work too. In
the test case below after the '1' is thrown you could
print(Components.lastResult); and see that the '1' was propagated.

The throw of a plain JS object uncovered a bug (that I have fixed). xpconnect
uses a the heuristic that if the thing thrown is JSObject and it has a 'message'
property and a 'code' property then we will wrap it as a nsIXCPException. That
code was a little broken and the fact that you are throwing an object with a
'messge' prop but no 'code' prop confused it.

What it was supposed to do is do a toString on the objects, build and exception
using that string as the messsage and a code of NS_ERROR_XPC_JS_THREW_JS_OBJECT.
This is fixed.

Comment 2

[John Bandhauer]

Also... I relized that 'throw 1' is a loser way to return a success code. I've
added 'Components.returnCode' as an alternate means to get and set the nsresult
that the calling native code will receive. Thowing is still the prefered way to
signal failure, but both throwing and setting Components.returnCode will work
for setting the nsresult for any value.

This code is not yet in the tree, but will be soon.

Comment 3

[cbegle]

okay.  let me know:
- when you're checked in
- what should happen in this example for "throw 1" and "throw -1"

thanks

Comment 4

[cbegle]

throw 1 and throw -1 now throw an error.  i agree that's the right thing to do.
thanks. 9/7/99.