First of Alex mention one problem, non-NS_OK success values. We need to abolish these from the tree. I suspect this will have to be done manually since the cure will vary. There are also not that many of these so it shouldn’t be too hard to do by hand.

The next thing is to try to reduce the amount of code we currently have with calling patterns like these:

int foo = 0;
CallXPIDLFunc(&foo);
if (foo > 4) {…

I.e. code that ignores the potential error code from an XPIDL call. These can be one of three things:

1. In many many cases the called function will never throw (or will only throw in out-of-memory situations).
2. Most other cases these callsites are just plain wrong and does need to be fixed to forward the error.
3. In a rare few cases the code is intentionally ignoring the error and basically does an implicit try/catch around the call.

If we could automatically eliminate 1 using automated tools we would have a much clearer picture of how to handle 2 vs 3 I think.

We could fix 1 by other using rocs suggestion, or by saying that non-throwing functions implemented in js should have any exceptions logged and ignored. Or something like it.

One way to separate 2 vs. 3 once 1 is taken care of would be to automatically write a patch that turns ignored return values into try/catches, and then we can manually go through the patch and remove the try/catches for the callers that fall into 2.

That’s the one sentence lesson to get from the “Cleaner, more elegant, and harder to recognize” exception rant, http://blogs.msdn.com/oldnewthing/archive/2005/01/14/352949.aspx , only proper RAII code continues to work properly and does not unexpectedly break when you introduce exceptions.

Note that RAII code is a good thing in itself, converting the codebase to it would be a great thing, and the fact it makes exception “work” is only an added bonus.

Not sure this is worth it, but I thought I would mention it (again).

/be

/be

Mark: Mozilla 2 breaks binary compat as well as source API compat.

/be

If so, I don’t think we can accept this unless we are guaranteed to have a good c/c++ bridge to external libraries accessible from js.

Another item I should point out is XPCOM success codes other than NS_OK, like NS_SUCCESS_LOSS_OF_INSIGNIFICANT_DATA. Your rewriting could have two levels of problems with that. In C++, would you really want to throw a success code? In JS, we use Components.returnCode (well, we should, anyway) – how would that fit into the revised XPCOM model, going from JS to C++?

Also, could I bribe you into forcing JS components to use nsIException and/or Components.Exception more?

Fortunately, this is an overstatement.

I think we need to mark a whole lot of interfaces as “script-callable, but not implementable by script”. That would make address a lot of your problems right away and would also solve some other problems. I need to blog about this.