[reactordev]

You can’t guarantee the underlying memory so you can’t guarantee your app won’t blow up. You can handle errors, or expects, or however you want to call “exceptions” without the stdlib but you still have error states, you still have deterministic code branches, you may not have RTTI and non-deterministic std::exception but you still have the concept of an exception. The alternative is to segfault.

[jandrewrogers]

You are correct that there is code that solves a similar class of problems as exceptions. This code exists because it is can gracefully handle cases that exceptions handle poorly, in addition to the cases exceptions handle well. The literal C++ exceptions are an inferior tool.

It is trivial to “guarantee” the underlying memory and is idiomatic for a lot of software that cares about performance or reliability. That is code anyone can write if they care. There isn’t much that can go wrong with memory allocation if you are not allocating memory from the system. No one is requiring C++ developers to poorly duct tape a bunch of rubbish STL together and call it an app. That simply isn’t something you see much in the hardcore systems domains where C++ is the tool of choice.

Somehow, mission-critical software is routinely written in C++ without exceptions and it works just fine. Error states are a normal part of all code, no exceptions required since obviously many languages don’t have them. And no, the alternative is not a segfault. C++ is designed to work just fine without exceptions. The language allows you to bring your own error/exception handling models with minimal overhead, same way you can import alternative ownership/safety models.

[reactordev]

“Error states are a normal part of all code, no exceptions required since obviously many languages don’t have them.”

An error and an exception are the same concept. Yes, it’s true that not using the std::exception class or any template named “exception” is exception free code. But you’re just lying to yourself. An error check or an assert or verify not <condition> is a “catch”.

[thegrim33]

No, they're not the same concept, they're both ways to express error conditions but they way they function are very different. People very intentionally do not use exceptions because of how they function and the potential impact on performance compared to other ways of error handling. As well as having other negatives, which other people below have listed when you made a similar comment.