112

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:

  • Stick to C's assert. Since the program is terminated immediately, it does not matter whether changes are correctly unrolled. Also, using #defines in C++ is just as bad.
  • Throw an exception and catch it in main(). Allowing code to skip destructors in any state of the program is bad practice and must be avoided at all costs, and so are calls to terminate(). If exceptions are thrown, they must be caught.
  • Throw an exception and let it terminate the program. An exception terminating a program is okay, and due to 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.

Fabian Knorr
  • 3,134
  • 3
  • 20
  • 32
  • 27
    No, really, `logic_error` is the logic error. An error in the program's logic is called a bug. You don't solve bugs by throwing exceptions. – R. Martinho Fernandes Aug 21 '12 at 20:16
  • 2
    Very related - http://bytes.com/topic/c/answers/739717-assert-vs-std-logic_error – Luchian Grigore Aug 21 '12 at 20:17
  • 5
    Assertions, exceptions, error codes. Each has a completely distinct use case, and you shouldn't use one where another is needed. – Kerrek SB Aug 21 '12 at 20:19
  • 1
    @R.MartinhoFernandes See http://www.cplusplus.com/reference/std/stdexcept/logic_error/ – Fabian Knorr Aug 21 '12 at 20:23
  • @KerrekSB My question is more about iplementing assertions in terms of exceptions. – Fabian Knorr Aug 21 '12 at 20:23
  • 7
    Make sure you use `static_assert` where it's appropriate if you have that available. – Flexo Aug 21 '12 at 20:23
  • 4
    @trion I don't see how that helps. Would you throw `std::bug`? – R. Martinho Fernandes Aug 21 '12 at 20:24
  • pretty sure @R.MartinhoFernandes knows what it is - he's saying you shouldn't use it as it isn't appropriate. – Flexo Aug 21 '12 at 20:24
  • 3
    @trion: Don't do that. Exceptions are not for debugging. Someone might be catching the exception. There's no need to worry about UB when calling `std::abort()`; it will just raise a signal that causes the process to terminate. – Kerrek SB Aug 21 '12 at 20:52
  • 2
    @R.MartinhoFernandes You can't fix bugs by throwing exceptions, but you can discard an untrustworthy result and continue with unrelated tasks if you don't trigger an abort. If an assert makes it into production code, that's *guaranteed* failure regardless of how important the failing assertion is to the caller's overall goals. –  Aug 29 '17 at 01:36

5 Answers5

110

  • 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.)

Languoguang
  • 2,166
  • 2
  • 10
  • 15
Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • 1
    came looking for this re assert; any form of assert passing through to production code points to poor design and QA. The point where an assert is called is where graceful handling of an error-condition should be. (I _never_ use assert's). As for exceptions, the _only_ use-case I know of is when ctor may fail, all others are for normal error-handling. – slashmais May 23 '16 at 08:21
  • 10
    @slashmais: The sentiment is laudable, but unless you're shipping perfect, bug-free code, I find an assertion (even one that crashes the user) preferable to undefined behaviour. Bugs happen in complex systems, and with an assertion you have a way of seeing and diagnosing it where it happens. – Kerrek SB May 23 '16 at 08:50
  • @KerrekSB I'd prefer to use an exception over an assertion. At least the code has a chance to discard the failing branch and do something else useful. At the very least, if you're using RAII, all your buffers to open files will get flushed properly. –  Aug 29 '17 at 02:12
  • "I never use assert's". A while back, this Turing guy thought they were pretty important, and he seemed to know a lot about computer stuff, so I'm going with his opinion instead. – Ron Burk Nov 11 '22 at 03:40
88

Assertions are entirely appropriate in C++ code. Exceptions and other error handling mechanisms aren't really intended for the same thing as assertions.

Error handling is for when there's a potential for recovering or reporting an error nicely to the user. For example if there's an error trying to read an input file you may want to do something about that. Errors could result from bugs, but they could also simply be the appropriate output for a given input.

Assertions are for things like checking that an API's requirements are met when the API wouldn't normally be checked, or for checking things the developer believes he's guaranteed by construction. For example if an algorithm requires sorted input you wouldn't normally check that, but you might have an assertion to check it so that debug builds flag that kind of bug. An assertion should always indicate an incorrectly operating program.

If you're writing a program where an unclean shutdown could cause a problem then you may want to avoid assertions. Undefined behavior strictly in terms of the C++ language doesn't qualify as such a problem here, since hitting an assertion is probably already the result of undefined behavior, or the violation of some other requirement which could prevent some clean-up from working properly.

Also if you implement assertions in terms of an exception then it could potentially be caught and 'handled' even though this contradicts the very purpose of the assertion.

bames53
  • 86,085
  • 15
  • 179
  • 244
  • 1
    I'm not entirely sure if this was stated specifically in the answer, so I'll state it here: you shouldn't use an assertion for anything involving user input that can't be determined at the time of writing the code. If a user passes `3` instead of `1` to your code, in general it should not trigger an assertion. Assertions are only programmer error, not user of the library or application error. – S.S. Anne Jan 05 '20 at 02:06
14

Assertions can be used to verify internal implementation invariants, like internal state before or after execution of some method, etc. If assertion fails it really means the logic of the program is broken and you can't recover from this. In this case the best you can do is to break as soon as possible without passing exception to the user. What is really nice about assertions (at least on Linux) is that core dump is generated as a result of process termination and thus you can easily investigate the stack trace and variables. This is much more useful to understand the logic failure than exception message.

nogard
  • 9,432
  • 6
  • 33
  • 53
  • I have a similar approach. I use assertions for logic which should be probably correct *locally* (e.g. loop invariants). Exceptions are for where a logic error was *forced upon* the code by an nonlocal (external) situation. – spraff Jul 23 '16 at 14:33
  • If an assertion fails, it means the logic of **part** of the program is broken. A failed assertion doesn't necessarily imply that *nothing* can be accomplished. A broken plugin probably shouldn't abort an entire word processor. –  Aug 29 '17 at 01:48
13

Not running destructors due to calling abort() is not undefined behaviour!

If it were, then it would be undefined behaviour to call std::terminate() too, and so what would be the point in providing it?

assert() is just as useful in C++ as in C. Assertions are not for error handling, they're for aborting the program immediately.

Darwyn
  • 4,696
  • 3
  • 25
  • 26
Jonathan Wakely
  • 166,810
  • 27
  • 341
  • 521
  • 1
    I'd say `abort()` is for aborting the program immediately. You're right that assertions are not for error handling though, yet assert does try to handle the error by aborting. Shouldn't you instead throw an exception and let the caller handle the error if it can? After all, the caller is in a better position to determine if the failure of one function makes it not worth doing anything else. Maybe the caller is trying to do three unrelated things and could still complete the other two jobs and just discard this one. –  Aug 29 '17 at 01:45
  • And `assert` is defined to call `abort` (when the condition is false). As for throwing exceptions, no, that's not always appropriate. Some things cannot be handled by the caller. The caller cannot determine if a logic bug in a third-party library function is recoverable, or if corrupt data can be fixed. – Jonathan Wakely Sep 04 '17 at 16:19
6

IMHO, assertions are for checking conditions that if violated, make everything else nonsense. And therefore you cannot recover from them or rather, recovering is irrelevant.

I would group them into 2 categories:

  • Developer sins (e.g. a probability function that returns negative values ):

float probability() { return -1.0; }

assert(probability() >= 0.0)

  • The Machine is broken (e.g. the machine which runs your program is very wrong):

int x = 1;

assert(x > 0);

These are both trivial examples but not too far from reality. For example, think about naive algorithms that return negative indexes for using with vectors. Or embedded programs in custom hardware. Or rather because sh*t happens.

And if there is such development mistakes you should not be confident about any recovering or error handling mechanism implemented. The same applies for hardware errors.

FranMowinckel
  • 4,233
  • 1
  • 30
  • 26