313
edits
Exceptions: Difference between revisions
→Exceptions for OOM
| Line 53: | Line 53: | ||
'''Compensate, then continue.''' This is like the previous case, except that no error code is returned--execution continues. Again, because we are not propagating the exception, we need a catch block. Again, we do have the option of using stack compensation objects and an empty catch block. | '''Compensate, then continue.''' This is like the previous case, except that no error code is returned--execution continues. Again, because we are not propagating the exception, we need a catch block. Again, we do have the option of using stack compensation objects and an empty catch block. | ||
=== | === Special Case Error: OOM === | ||
In current FF, <code>new</code> returns a null pointer when OOM, but with exceptions enabled, it will throw <code>std::bad_alloc</code>. | In current FF, <code>new</code> returns a null pointer when OOM, but with exceptions enabled, it will throw <code>std::bad_alloc</code>. | ||
On most platforms, this shouldn't matter too much, as true OOMs are rare anyway. But we would of course like FF not to crash in this case, which requires catching <code>std::bad_alloc</code>. | On most platforms, this shouldn't matter too much, as true OOMs are rare anyway. But we would of course like FF not to crash in this case, which requires catching <code>std::bad_alloc</code>. The easy way to do this is to refactor these call sites as described for generic errors. A more ambitious solution is to remove most of the catch blocks for OOMs, make the call sites exception-safe, and catch OOMs at a high level. That way, there would be very little code devoted to OOM handling. | ||
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 === | === Exceptions for nsresult rv != NS_OK === | ||