Exceptions

This is a discussion document for ideas about how to use static analysis to help refactor Mozilla to use C++ exceptions instead of nsresults.

1. nothrow

The first step is to get the list of methods that never throw exceptions so that error handling can be removed entirely at their call sites.

The basic analysis idea is that a nsresult-returning method is nothrow if it always returns NS_OK and never allocates memory. The main problem is that it's hard to analyze a method that calls other methods. It's easy to conservatively assume that any method that makes a call can throw, but that might miss too many nothrows. If so, we can try a conservative call graph approximation (i.e., one that doesn't need points-to analysis).

Once that analysis is in place, we know that the return value is 0 and we can do dead branch elimination on the call sites and make the call sites ignore the return value.

We should probably also annotate nothrows in some way, which also gives us the opportunity to discover more of them manually later on.

2. ignored nsresults

Once the nothrows are identified and put aside, I'd like to assume that all other call sites that use nsresult methods "do the right thing". But there may be call sites that ignore the return value, which would make them potentially exception unsafe. So the second step is an analysis to flag all of these locations.

Roughly, the analysis should flag a call site where:

  (a) the method is not nothrow
  (b) there is no branch on NS_FAILED(rv) or NS_SUCCEEDED(rv)

The easy way to do (b) is to just look for if statements where the condition refers to NS_FAILED or NS_SUCCEEDED on the variable where the result goes. But that's not perfect, because of things like:

- Calling NS_FAILED directly on the function without a variable - Assigning the rv or the NS_FAILED test result to a variable then branching later - Overwriting the value of rv before the test (so the rv isn't actually branched on)

The easy way might be good enough for our purposes. If not, we can design an abstract interpretation that is more precise.

3. tested nsresults

This is all the nsresult call sites not already covered. Finally, the hard one. My first thought is that we can look at the success and failure paths through the code and rearrange them to use exceptions. In most cases, the test should just be an if that branches on NS_FAILED or NS_SUCCEEDED, so that we can easily identify the success path and the failure path. Then, we can (logically) rewrite the code so it has this form:

  nsresult rv = callSomeMethod();
  maybe some_junk();
  if (NS_FAILED(rv)) {
     maybe fixup();
     maybe return rv;
     maybe return NS_ERROR_FOO;
     maybe return 0;
  } else {
     maybe do_stuff();
  }

Having some_junk() would be very annoying--hopefully it is rare and we can just flag it for manual fixing. Otherwise, we rewrite the code to use exceptions. I think there are several distinct rewrite patterns depending on the return values and the presence of the various fixups. Hopefully they can be fit into a small number of basic categories.

- Case 1: return rv in orig code

     FixupMgr f;
     callSomeMethod();
     maybe do_stuff();

- Case 2: all others

     try {
         callSomeMethod();
         maybe do_stuff();
     } except (nserror e) {
        maybe fixup();
        maybe throw NS_ERROR_FOO;
        maybe return;
     }

In case 2 it is also an option to use a FixupMgr.

One significant glitch is see is when the error handling block uses constructs like

X1. NS_FAILED(rv) || foo X2. NS_FAILED(rv) && foo X3. NS_FAILED(rv1) || NS_FAILED(rv2) X4. NS_FAILED(rv1) && NS_SUCCEEDED(rv2)

These seem to be pretty common. Some thoughts on handling them:

X1. Here we can duplicate the failure code. The code to be dup'd should be small if we use FixupMgrs.

X2. Here we can guard the catch block actions with the additional condition foo.

X3 & X4 seem harder, maybe not worth thinking about right now. Hopefully there are not too many. X1 and X2 are common, though, I think.

Dave