If you're not catching the exception, you should set the new
handler so that it doesn't occur. (Most of my programs set the
new handler to generate an error message and abort.)
That depends a lot on your application...
And the context in which it runs... On many systems (Linux,
Windows), you can't handle out of memory anyway, at least in the
default configurations. And on most systems, you can't
systematically handle it---only if it occurs in a new.
Well, you could always stop that particular operation that the user wanted
and give him the option of doing something else.. Letting a program crash
is not really an acceptable to me...
Which is why you set the new handler.
Interrupting a given operation but continuing to handle others
is a good solution for many applications, if:
-- operations are more or less open, so that you cannot know
in advance the amount of memory an operation might need,
-- you can be sure that the out of memory condition will occur
during a new, and not, say, because of stack overflow (most
of the cases I've seen of "open" operations have involved
recursive descent parsing, which means that stack overflow
is more likely than out of memory), and
-- you are sure that the systems you are running on are
configured so that you can actually detect the condtion:
this is not the default configuration for Linux, and the one
time I experimented under Windows NT, I couldn't get an out
of memory condition either.
As a general rule, unless you take a number of special
precautions, you cannot exclude your programming crashing
because of a lack of memory.