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.
You should only use assert to check for situations that "can't happen", e.g. that violate the invariants or postconditions of an algorithm, but probably not for input validation (certainly not in libraries). When detecting invalid input from clients, be friendly and return an error code.
In the C Programming Language, assert is a macro that is designed to be used like a function. It checks the value of an expression that we expect to be true under normal circumstances. If expression is a nonzero value, the assert macro does nothing.
You should use assert to check all conditions that should never happen: Preconditions on input parameters. Results of intermediate calculations. Postconditions on object state.
Assertions should be used to check something that should never happen, while an exception should be used to check something that might happen. For example, a function might divide by 0, so an exception should be used, but an assertion could be used to check that the harddrive suddenly disappears.
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.
CWE-617: Reachable Assertion
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.)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With