Mozilla 2/Exceptions

Owners

Dave Mandelin (dmandelin), with lots of advice from Taras Glek and Jonas Sicking.

Status

There is a technical discussion article under Exceptions.

There are too many outstanding issues to estimate a completion date.

Overview and Motivations

The goal is to replace all nsresult-based error reporting and handling with C++ exceptions. Because about 50,000 method call sites are affected, we would like to automate most of the changes.

The main benefit is that error-handing code will become simpler and more concise, making it easier to read and hack on Mozilla code. For example, NS_ENSURE_RESULT lines will disappear. Secondary benefits include:

• Obviating bug 353144, which is that new is already throwing exceptions, which are not being handled properly.

• Enabling outparamdel.

• Making it possible to propagate the same exception through both native code from C++ and JS runtimes, including Tamarin.

• Possibly improving performance on the common case of no errors.

Risks and Assumptions

Performance may decrease. Footprint may increase.

Code that invokes CPP macros is difficult to rewrite automatically.

JS runtimes and the JS/C++ boundary (XPConnect) are closely tied with exceptions, and changes in JS could change how exceptions need to be done.

Enabling exceptions requires modifications to XPConnect: if the changes are platform/ABI-specific, they would need to be made to each implementation.

Schedule and Milestones

• Finish a gcc-based analysis framework. (In progress with Dehydra GCC.)

• Develop analyses to find and classify method call sites for manual or automatic rewriting. (Some work done using DeHydra Classic. See bug 407444.)

• Develop automatic rewriters. (See thrower.)

• Rewrite hard cases manually.

• Update XPConnect/Tamarin/etc. ?

References

Exception Safety

RAII for cleanup

Tamarin FFI, with comments on exceptions