What’s Next 76321
Using assert()Versus Exceptions ................................................................
Yesterday, you saw how to work with exceptions to handle error conditions. It is impor-
tant to note that assert()is not intended to handle runtime error conditions such as bad
data, out-of-memory conditions, unable to open file, and so forth. assert()is created to
catch programming errors only. That is, if an assert()“fires,” you know you have a bug
in your code.
This is critical because when you ship your code to your customers, instances of
assert()are removed. You can’t depend on an assert()to handle a runtime problem
because the assert()won’t be there.
It is a common mistake to use assert()to test the return value from a memory
assignment:
Animal *pCat = new Cat;
Assert(pCat); // bad use of assert
pCat->SomeFunction();
This is a classic programming error; every time the programmer runs the program,
enough memory is available and the assert()never fires. After all, the programmer is
running with lots of extra RAM to speed up the compiler, debugger, and so forth. The
programmer then ships the executable, and the poor user, who has less memory, reaches
this part of the program and the call to newfails and returns NULL. The assert(),how-
ever, is no longer in the code and nothing indicates that the pointer points to NULL. As
soon as the statement pCat->SomeFunction()is reached, the program crashes.
Getting NULL back from a memory assignment is not a programming error, although it
is an exceptional situation. Your program must be able to recover from this condition, if
only by throwing an exception. Remember: The entire assert()statement is gone when
DEBUGis undefined. Exceptions are covered in detail on Day 20.
Side Effects ....................................................................................................
It is not uncommon to find that a bug appears only after the instances of assert()are
removed. This is almost always due to the program unintentionally depending on side
effects of things done in assert()and other debug-only code. For example, if you write
ASSERT (x = 5)
when you mean to test whether x == 5, you create a particularly nasty bug.
Suppose that just prior to this assert(), you called a function that set xequal to 0. With
this assert(), you think you are testing whether xis equal to 5 ; in fact, you are setting x
equal to 5. The test returns truebecause x = 5not only sets xto 5 , but returns the value
5 , and because 5 is nonzero, it evaluates as true.