|
|
| Line 61: |
Line 61: |
| Code that allocates memory by means other than <code>new</code> (e.g., <code>malloc</code>) will need to be changed to throw <code>std::bad_alloc</code> on failure. | | Code that allocates memory by means other than <code>new</code> (e.g., <code>malloc</code>) will need to be changed to throw <code>std::bad_alloc</code> on failure. |
|
| |
|
| === Exceptions for nsresult rv != NS_OK === | | === Special Case Error: XPCOM Infrastructure === |
| | |
| | |
| | |
| XPConnect needs to be rewritten so that when JavaScript calls C++, the FFI catches C++ exceptions and generates JavaScript exceptions if necessary. Also, when C++ calls JavaScript, C++ exceptions should be generated in response to JavaScript exceptions. This is potentially a lot of work, because there are separate XPConnect implementations for every platform and compiler.
| |
| | |
| === Functions with Special Requirements ===
| |
|
| |
|
| <code>QueryInterface</code> may be redesigned so that it never throws an exception. It will simply return a null pointer on failure, and callers must check for it if there is a possibility of failure. (Many <code>QueryInterface</code> calls are guaranteed to succeed.) | | <code>QueryInterface</code> may be redesigned so that it never throws an exception. It will simply return a null pointer on failure, and callers must check for it if there is a possibility of failure. (Many <code>QueryInterface</code> calls are guaranteed to succeed.) |
| Line 75: |
Line 69: |
| <code>CreateInstance</code> might also generate OOMs only, although other failure modes are possible. (TBD) | | <code>CreateInstance</code> might also generate OOMs only, although other failure modes are possible. (TBD) |
|
| |
|
| === nothrow Functions ===
| |
|
| |
|
| Some methods always return <code>NS_OK</code>. In this case, the <code>nsresult</code> returned is pure waste, and the translation to use exceptions is particularly easy: all return statements are stripped of their value, call sites that ignore the result are unchanged, and call sites that test the value are partially evaluated for the return value <code>NS_OK</code>.
| | === XPConnect === |
|
| |
|
| One problem with this is that functions that never throw an exception today might someday be changed to throw an exception. Their call sites might then behave incorrectly when exceptions are thrown.
| | XPConnect needs to be rewritten so that when JavaScript calls C++, the FFI catches C++ exceptions and generates JavaScript exceptions if necessary. Also, when C++ calls JavaScript, C++ exceptions should be generated in response to JavaScript exceptions. This is potentially a lot of work, because there are separate XPConnect implementations for every platform and compiler. |
| | |
| One "solution" to this problem that isn't currently being planned is to annotate methods as '''nothrow''' and check this annotation in the compiler. First, these extra annotations are annoying and inflexible (q.v. checked exceptions in Java). Second, they aren't checked by a standard compiler, so chances are, they will eventually become wrong.
| |
| | |
| The approach now under consideration is simply to be very careful about introducing new throw statements.
| |
| | |
| The definitive solution, also under consideration, is to make FF methods exception-safe. This means that even when an exception is thrown, all program invariants are maintained. The most common invariant to be maintained is not to leak memory or other resources. However, there are other invariants, such as counters and flags, that must also be protected.
| |
|
| |
|
| === outparamdel === | | === outparamdel === |