[thedance]

Stroustrup constructs a bit of a false dichotomy there. He presents the choice between exceptions and explicit error propagation and checking, but there is a third way. If the allocator is simply infallible and std::bad_alloc just doesn't exist, and the program terminates on allocation failure instead, then you need neither exceptions nor error codes. Since std::bad_alloc is such a prominent root cause of all exceptions, and since it's preposterous to believe a program can continue after the global allocator stops working, this turns out to be a dramatic simplification of the overall program. Once you get rid of allocator exceptions it's not a big mental leap to just decide to get rid of all of them.

[usrnm]

But std::bad_alloc does exist and it's possible and sometimes necessary to write correct software that's able to handle allocation errors. What we probably need is some sort of a compiler switch, but it will significantly complicate writing generic multi-purpose libraries

[thedance]

bad_alloc doesn't just naturally spring into being. If you override operator new, your implementation may not use it (for example tcmalloc does not throw if it can't allocate, it logs a message and terminates the program). Many systems of the type you mention, embedded control systems and the like where correctness actually matters, don't use new and delete anyway. They often use placement new with space statically allocated at program startup. These are the same kinds of projects that often decide to not use exceptions.

[ncmncm]

When the global allocator fails, you might not be able to do much... except set a flag, and free a big block of memory that was reserved against just such an event.

Then the program can do whatever cleanup is warranted, maybe freeing up a variety of other resources, and then maybe re-reserve that block, and forge ahead.

But when you actually care about performance, you often are not using the global allocator. A local allocation failure is nothing to panic over. Generally, only the higher level code -- where the handler is -- knows, or needs to care, what kind of allocator failed. The low-level code gets to just bail out, as it should.

[hoseja]

You could also have just tried to allocate 42 terabytes of memory and have a well defined strategy for what to do in case this fails...

[daemin]

Yeah, but in that case you would use your own allocator fit for this purpose and not just new or malloc.

[jfkebwjsbx]

bad_alloc does not mean the allocator has stopped working. It only means that a particular allocation cannot be served.

And there are plenty of other root causes for exceptions in real programs, not just allocations.

That does not mean one needs exceptions, though.