How often do you check for an exception in a C++ new instruction?

Question

I just started reading Effective C++ today and got to the point where the author talks about the operator new.

The book explains very well how you can catch (with various degrees of elegance) the std::bad_alloc exception that the operator new can raise if you run out of memory.

My question is: How often do you check for the case when there isn't enough memory to instantiate a object, if at all? and why? Is it worth the hassle?

Answer 1

I catch exceptions when I can answer this question:

What will you do with the exception once you've caught it?

Most of the time, my answer is, "I have no idea. Maybe my caller knows." So I don't catch the exception. Let it bubble up to someone who knows better.

When you catch an exception and let your function proceed running, you've said to your program, "Never mind. Everything's fine here." When you say that, by golly, everything had better be fine. So, if you've run out of memory, then after you've handled std::bad_alloc, you should not be out of memory anymore. You shouldn't just return an error code from your function, because then the caller has to check explicitly for that error code, and you're still out of memory. Your handling of that exception should free some memory. Empty some caches, commit some things to disk, etc. But how many of the functions in your program do you really want to be responsible for reducing your program's memory usage?

If you cannot solve the problem that triggered the exception, then do not handle the exception.

Answer 2

The problem is that when you run out of memory there is generally not much you can do except write to a crash dump and exit the program. It's therefore useless to check every new in your program.

One exception to this is when you allocate memory for e.g. loading a file, in which case you just need to inform the user that not enough memory is available for the requested operation.

Answer 3

I think the most important thing is to always be conscious of the possibility you might run out of memory. Then decide whether you care or not. Consider trying and catching for each and every allocation -- that's a lot of a hassle. Pick between increased productivity and simpler code versus an application that can gracefully handle the case of no-memory. I think both gains are extremely valuable in the right contexts, so choose carefully.

Yes, you can make your life easier by defining a template base-class that provides a custom operator new and operator delete and sets a new new-handler. Then you can use the Curiously Recurring Template pattern to derive from this base class. Your derived classes will then gracefully handle bad allocations, but you still need to remember to derive from that base-class on each new class you create. Often you may end up with multiple-inheritance, which may bring complexities of its own. No matter what you do to handle bad allocations, your code will not be as simple as if you don't bother.

There is never one answer to this. It is a choice you must make, depending on the context as always.