I agree with the sentiment but in practice I’ve found that most C++ STL exceptions throw in a “fatal error” type of scenario like a bad allocation and generally not an “expected error”. For example, basic_ifstream::open() sets a fail bit on error, and doesn’t throw an exception.
This is in contrast to python or Swift for example, their standard libraries are more “throw-prone”. Building off the previous example Swift’s String.init(contentsOf:encoding:) throws on error on failure.
So in practice, IMO it is usually safe to disable exceptions in C++. Though, I have run into tricky ABI breaks when you link multiple libraries in a chain of exceptions->noexcept->exceptions and so on! You’re of course at the mercy of nonstandard behavior so buyer-beware. I definitely wouldn’t advocate for turning them off -just- for a binary size reduction.
You can recover from failed allocations without catastrophic failure. It is a fundamentally lazy programming practice to pretend that error handling has to be an out of band operation that can't be dealt with locally and bubble up progressively.
You can try but realistically, you shouldn't bother in the overwhelming majority of software. Depending on whether you're on a platform that allows for overcommit, you won't necessarily know that an allocation has failed until you attempt to make use of it and the OS tries to back the pages, by which point, you could be far from the source of the allocation.
You're just going to end up with an insane amount of error handling only to discover that in the real world, there's likely nothing you can really do anyway.
On platforms that allow overcommitment, you can guarantee your commit charge is physically backed by writing to each page in a memory pool at allocation time (probably at application startup, or at the end of the main loop), then allocating out of that pool.
Using memory that's been allocated but not committed seems like a recipe for disaster.
This is in contrast to python or Swift for example, their standard libraries are more “throw-prone”. Building off the previous example Swift’s String.init(contentsOf:encoding:) throws on error on failure.
So in practice, IMO it is usually safe to disable exceptions in C++. Though, I have run into tricky ABI breaks when you link multiple libraries in a chain of exceptions->noexcept->exceptions and so on! You’re of course at the mercy of nonstandard behavior so buyer-beware. I definitely wouldn’t advocate for turning them off -just- for a binary size reduction.