3

I'm fine tuning a little project and I've read that I can get errors if I attempt to create a new object and it returns an error if it fails (corrupted memory, out of memory?).

So I was thinking, in the line below:

Object* myObj = new Object();

How is it usually done in projects?

Object* myObj;
try
{
    myObj = new Object();
}
catch (std::bad_alloc&)
{ 
    //Deal with the Error 
}

or...

Object* myObj = new (std::nothrow) Object();
if(!myObj)
{
    //Deal with the Error
}

I'm assuming #2 is the best action, since try/catch every new seems too much overhead.

Just the thought of hunting all the new keywords and adding error checking everywhere is... discouraging. Are there any other options? Or some option to make (std::nothrow) as default operation for new?

Danicco
  • 1,573
  • 2
  • 23
  • 49

2 Answers2

1

Failure to allocate probably is such a major error that the program have to be terminated anyway, so if anything it's more often handled at a higher level (if at all) where the handling of the error is to simply inform the user about it and then exit.

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
  • By higher level you mean such as in the main loop? Wouldn't that kill performance? It's a game engine and there's a bunch of (new) everywhere when there's a load or even during gameplay, so I'm looking for a good option of "gracefully failing". – Danicco Sep 05 '13 at 06:23
  • 1
    @Danicco Exceptions and exception handling only takes time when an exception is actually thrown. If no exception happens, then there should not be any performance penalty. Also, by "higher level" I mean the highest level that can handle the exception in any meaningful way. Doing it at the place you try to allocate is often not good, since there's nothing more you can do than report it. At a higher level you could do some "garbage collection" of your own, by trying to free things you don't need anymore. – Some programmer dude Sep 05 '13 at 06:32
  • 1
    @JoachimPileborg Depending on the application, the stack walkback might be all it takes to "garbage collect". – James Kanze Sep 05 '13 at 08:17
1

It depends, it depends on how you want to treat the error in your specific code path.

If your code can check the error and move on with a different code path on error, say take a different condition or return an error to user while the program continues, then nothrow option is better. If your program cannot proceed if you run out of memory (the more common case) then instead of doing a try/catch on each new, you could catch the exception at the top level (main) and log the right error and abort the program.

jayadev
  • 3,576
  • 25
  • 13
  • Doing it in main seems a little superfluous. The program will report the error anyway and terminate the program. Any allocated memory will be freed when the process dies. The only case I can imagine is if you wanted to log it in a file or the program wanted a GUI error, but then that's dangerous because GUI takes memory you don't have. – Cramer Sep 05 '13 at 07:16
  • @Cramer Catching it in main may be superfluous some times, but not always; in interactive programs, you might want to save some of the work. And on servers, it's not unusual to catch it at the transaction level. The stack unwinding and the end of the transaction should free up enough memory for other transactions, and you report an error for this one particular transaction (too complicated, etc.). – James Kanze Sep 05 '13 at 08:15