[ACCEPTED]-What is the strategy if assertion fails-assertion

Accepted answer
Score: 24

If the assertion fails, the program should crash.

An assertion failing 19 means the programmer made a fundamental 18 mistake in their understanding of how it 17 is possible for the program flow to proceed. This 16 is a development aid, not a production aid. In 15 production, one might handle exceptions, as they "might" occur, whereas 14 assertions should "never" fail.

If you're 13 in the camp that says, "Oh, but what if 12 assertions fail in production? I need to 11 catch them!" then you're missing the point. Ask 10 yourself, in such a case, why aren't you just throwing an exception (or otherwise 9 handling the error)?

Generally speaking, assert is 8 not just a shorthand for "if condition not 7 met, throw exception" (well, sometimes that's 6 the operational semantics, but it's not 5 the denotational semantics). Rather, an 4 assertion failing means the application 3 is in a state the developer does not believe is even possible. Do you really want the code to continue 2 executing in such a case? Clearly (I would 1 say), No.

Score: 2

Defensive programming is always best. You 18 should always assume that despite all your 17 testing, your application will ship with 16 bugs. As such, it is in your best interests 15 to add NULL checks in situations where you 14 can avoid a NULL pointer deference and simply 13 move on.

However, there are situations where 12 there is simply no easy way to avoid a crash, and 11 in those cases, the assert is your only 10 way of detecting the problem during your 9 development cycle.

One important point though 8 - asserts are also often used to detect 7 major problems with the integrity of your 6 data. If you continue past those asserts, you 5 might risk corrupting data. In those cases, it 4 may be better to crash rather than destroying 3 your data. (Obviously, any sort of crash 2 handler that at least brings up a reasonable 1 UI with an error description would be preferable).

Score: 1

Assertions are debugging code, not operating 1 code. Do not use them to catch input errors.

Score: 1

Strictly speaking, the second code has redundancy.

void f(int *p)
{
  assert(p);
  if (p)    // Beats the purpose of assertion
  {
    p->do();
  }
}

Assertion 16 means error has occurred. Something which 15 is unexpected/unhandled. In above code, either 14

1) You are properly handling the case where 13 p is null. (by not calling p->do())- which 12 supposedly is the right/expected thing to 11 do. However, then the assertion is a false alarm.

2) On 10 the other hand, if by not calling p->do(), something 9 will go wrong (maybe further in the code 8 or in the output), then the assertion is 7 right, but there should be no point in continuing 6 anyways.

In the above code the programmer 5 is working extra hard to handle cases which 4 are erroneous anyways.

That said, some people 3 like to treat asserts as something has gone wrong, but lets see if we still get correct output. IMO, that is 2 bad strategy and creates confusions during 1 bug fixing.

Score: 0

Assertions are used to catch bugs in testing. The 6 theory is that you've tested well enough 5 to know that it will work once you've released 4 it.

If there's any possibility that the condition 3 might arise in real life operation, don't 2 rely on assertions - use exceptions or some 1 other error mechanism.

Score: 0

Asserts are useful for debugging as you 8 mentioned. They should never make it into 7 production code (as compiled, it's ok to 6 wrap them in #ifdefs of course)

If you're 5 running into an issue where it's beyond 4 your control to rectify and you need the 3 check in your production code I'd do something 2 like:

void f(int *p)
{

  if (!p)
  {
    do_error("FATAL, P is null.");
  }

  p->do();
}

Where do_error is a function that logs 1 an error and cleanly exits.

Score: 0

I say leave them in in à release build. There 8 are bound to be bugs in any build. Having 7 asserts in your product means you can pinpoint 6 the problem more easily when you receive 5 à problem report from à uwer.

Do not put 4 much effort in handling the exceptions. Simply 3 make sure you can get hold of the complete 2 exception, includigg stacktrace. That applies 1 to à release build in particular.

Score: 0

Since many people are commenting on putting 15 assertions in release mode:

In what I work 14 on, efficiency is very important (sometimes, execution 13 on large data sets takes dozens of hours 12 to few days to complete). Hence, we have 11 special macros that assert only in debug 10 code (run during QA etc). As an example, an 9 assert inside a for loop is definitely an 8 overhead and you may want to avoid it in 7 release code. After all, if all iz well, asserts 6 are not supposed to fail.

One example where 5 release code asserts are good is -- if logic 4 is not supposed to hit a particular branch 3 of code at all. In this case, assert(0) is 2 fine [thus any kind of assert(0) can always 1 be left in release code].

More Related questions