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.