Consider what you are doing. You're allocating memory. And if for some reason memory allocation cannot work, you assert
. Which is more or less exactly what will happen if you just let the std::bad_alloc
propagate back to main
. In a release build, where assert
is a no-op, your program will crash when it tries to access the memory. So it's the same as letting the exception bubble up: halting the app.
So ask yourself a question: Do you really need to care what happens if you run out of memory? If all you're doing is asserting, then the exception method is better, because it doesn't clutter your code with random assert
s. You just let the exception fall back to main
.
If you do in fact have a special codepath in the event that you cannot allocate memory (that is, you can actually continue to function), exceptions may or may not be a way to go, depending on what the codepath is. If the codepath is just a switch set by having a pointer be null, then the nothrow
version will be simpler. If instead, you need to do something rather different (pull from a static buffer, or delete some stuff, or whatever), then catching std::bad_alloc
is quite good.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…