I tend to add lots of assertions to my C++ code to make debugging easier without affecting the performance of release builds. Now, assert
is a pure C macro designed without C++ mechanisms in mind.
C++ on the other hand defines std::logic_error
, which is meant to be thrown in cases where there is an error in the program's logic (hence the name). Throwing an instance might just be the perfect, more C++ish alternative to assert
.
The problem is that assert
and abort
both terminate the program immediately without calling destructors, therefore skipping the cleanup, whereas throwing an exception manually adds unnecessary runtime costs. One way around this would creating an own assertion macro SAFE_ASSERT
, which works just like the C counterpart, but throws an exception on failure.
I can think of three opinions on this problem:
#define
s in C++ is just as bad.NDEBUG
, this will never happen in a release build. Catching is unnecessary and exposes implementation details of internal code to main()
.Is there a definitive answer to this problem? Any professional reference?
Edited: Skipping destructors is, of course, no undefined behaviour.
Assertions are for debugging. The user of your shipped code should never see them. If an assertion is hit, your code needs to be fixed.
The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.
While assertion is good for catching logic errors and reducing the chances of reaching more serious vulnerability conditions, it can still lead to a denial of service.
For example, if a server handles multiple simultaneous connections, and an assert() occurs in one single connection that causes all other connections to be dropped, this is a reachable assertion that leads to a denial of service.
Exceptions are for exceptional circumstances. If one is encountered, the user won't be able to do what she wants, but may be able to resume somewhere else.
Error handling is for normal program flow. For instance, if you prompt the user for a number and get something unparsable, that's normal, because user input is not under your control and you must always handle all possible situations as a matter of course. (E.g. loop until you have a valid input, saying "Sorry, try again" in between.)