Often there are two ways to write code. One way is to design an API and have code patterns adhere to how the API is supposed to be used. Another way is to rely on language features to accomplish the same thing. Typically API-pattern approaches are chosen because compilers are too immature or just don’t provide the necessary features. Sometimes compilers do catch up and the possibility of utilizing newer language features appears.

In the case of the exception rewrite the task is to rewrite code from a pattern-based (compiler in your head) approach to a more strict C++ construct-based exception paradigm. Unfortunately APIs don’t enforce their usage as much as a compiler (in part because we don’t have app-spefic compiler plugins) so transforming that into a strict compiler-friendly form automatically isn’t always realistic (example). See my previous post for more examples.

Having done more work on the exception conversion I believe that it is possible to switch Mozilla to exceptions to the point of getting it to compile. Unfortunately, I don’t think that it’s possible to do this in the Mozilla2 timeframe due to the large amount of manual labour required.

Due to various use cases that don’t fit the exception model there is a need for an nsresult-lint tool to detect funny (see above) nsresult patterns so code can be manually fixed to enable thrower to transform code correctly.

I expect conversion to exceptions to consist of the following large steps:

XPCOMGC -> nsresult-lint -> thrower automatic conversion -> nsexception-lint -> outparamdel

  1. XPCOMGC needs to land first to simplify memory management. Otherwise there will be a lot more nsCOMPtr<>s already_AddRefed<>s and friends.
  2. nsresult-lint would flag code for clean up to assist with the multitude of special cases in the code preventing it from transformation
  3. thrower needs to do some reasonably sophisticated static analysis (sensitive to control flow) to ensure that code is rewritten correctly. The analysis step isn’t ridiculously hard, but it is considerably more complex than what is done in existing tools.
  4. nsexception-lint tool will flag exception-unsafe code. I expect this to highlight a fair amount of code that needs to be converted to RAII. It will take more manual labour to fix flagged code here than in than step2.
  5. Once exceptions are used the return value is freed up for outparamdel to utilize. This will be a nice optimization and code clean up.

I think the best bet with exceptions would be to start working on them during the moz2 development cycle to have them land early in post-moz2.

Or as an alternative we could try to do just the OOM exceptions which are less frequent which would look like:

XPCOMGC -> thrower automatic conversion(OOM cases are easier) -> nsexception-lint

In this case the only significant piece of work is nsexception-lint which would be needed later for a full-blown exception rewrite. It wouldn’t be so bad to convert code to RAII even before that is required for the full exception rewrite.

For now I’m going let thrower rest in the pork hg repository while I try to make a static checker plugin for gcc.
Feel free to ask for clarification. I’m dealing with after-effects of insomnia so this may not be completely clear.

Update: Reasonable description of RAII.


  1. forgive my ignorance on the subjects you deal with, but what is the RAII related step/work about (as in, what does that acronym mean)

  2. Callek,
    Added a link for you.

  3. Robert O'Callahan

    That manual labour would parallelize easily. What makes you think it can’t be done for Mozilla2?

  4. Robert,
    I think this would be moz2 material if I had the tools already written.
    As it stands I have to write the tools and only then everybody else should drop what they are doing and fix their part of the code (which I admit wouldn’t take too long).
    I’m guessing it’d take me 4months to get the tooling done. This would be during or after XPCOMGC work.
    I don’t think a long delay is what we want for moz2 as it would delay the release further. OOM handling on the other hand is a nice babystep to start from and if that turns out easier than expected could always decide to do the rest of the rewrite.

  5. I guess sometimes you have to know when to stop working on something and ship.

  6. Doesn’t the latest mozilla2 status include “Exception support” in the list of “Big, invasive, destabilizing changes” mozilla 2 changes ?
    And the (outdated?) timeline ( http://wiki.mozilla.org/Mozilla_2 ) is to ship Fx4/Moz2 at best in Q12009, so if after the tooling is there it can be parallelized, it should work.

  7. as a newbie in this field i wish to thank you for this very useful information