The main concern for the case you described is where you should catch that exception, not if you should catch it. I'd say don't catch an out of memory exception within an initialization routine, or within a load/parse routine for map data, but rather around the initialization or load/parse so the operation fails as a whole.
This is what I mean. The code in question looked a lot like this:
size_t absurdSize = 0xFFFFFFFF; /* This would usually come from user
input, not declared here like this */
try
{
new Map(absurdSize, absurdSize);
}
catch(std::bad_alloc& egad)
{
/* This is definitely not a fatal exception, the
program can easily continue normally here. */
std::cout << "Map size too big. Use reasonable dimensions." << std::endl;
}
/* note lack of trying to catch anything else because reasons. */
That kind of error leeor, could be solved with a bit of "if" logic, and thus wouldn't be as costly for the program to process ( at least that is what I've been told about catching exceptions ). For example:
if absurdsize > 1024:
absurdsize = 1024
Then if the concern was that they might give a value that would overflow (not sure right term) the integer, you would clamp the size of the input box down so that only a value of say 9999 could be put in it.