Editing Assertion (software development) (section)

== Comparison with error handling ==

Assertions are distinct from routine [[Exception handling|error-handling]]. Assertions document logically impossible situations and discover programming errors: if the impossible occurs, then something fundamental is clearly wrong with the program. This is distinct from error handling: most error conditions are possible, although some may be extremely unlikely to occur in practice. Using assertions as a general-purpose error handling mechanism is unwise: assertions do not allow for recovery from errors; an assertion failure will normally halt the program's execution abruptly; and assertions are often disabled in production code. Assertions also do not display a user-friendly error message.

Consider the following example of using an assertion to handle an error:

<syntaxhighlight lang="c">
int *ptr = malloc(sizeof(int) * 10);
assert(ptr);
// use ptr
...
</syntaxhighlight>

Here, the programmer is aware that <code>[[malloc]]</code> will return a [[Null pointer|<code>NULL</code> pointer]] if memory is not allocated. This is possible: the operating system does not guarantee that every call to <code>malloc</code> will succeed.  If an out of memory error occurs the program will immediately abort.  Without the assertion, the program would continue running until <code>ptr</code> was dereferenced, and possibly longer, depending on the specific hardware being used.  So long as assertions are not disabled, an immediate exit is assured.  But if a graceful failure is desired, the program has to handle the failure.  For example, a server may have multiple clients, or may hold resources that will not be released cleanly, or it may have uncommitted changes to write to a datastore.  In such cases it is better to fail a single transaction than to abort abruptly.

Another error is to rely on side effects of expressions used as arguments of an assertion. One should always keep in mind that assertions might not be executed at all, since their sole purpose is to verify that a condition which should always be true does in fact hold true. Consequently, if the program is considered to be error-free and released, assertions may be disabled and will no longer be evaluated.

Consider another version of the previous example:

<syntaxhighlight lang="c">
int *ptr;
// Statement below fails if malloc() returns NULL,
// but is not executed at all when compiling with -NDEBUG!
assert(ptr = malloc(sizeof(int) * 10));
// use ptr: ptr isn't initialised when compiling with -NDEBUG!
...
</syntaxhighlight>

This might look like a smart way to assign the return value of <code>malloc</code> to <code>ptr</code> and check if it is <code>NULL</code> in one step, but the <code>malloc</code> call and the assignment to <code>ptr</code> is a side effect of evaluating the expression that forms the <code>assert</code> condition. When the <code>NDEBUG</code> parameter is passed to the compiler, as when the program is considered to be error-free and released, the <code>assert()</code> statement is removed, so <code>malloc()</code> isn't called, rendering <code>ptr</code> uninitialised. This could potentially result in a [[segmentation fault]] or similar [[null pointer]] error much further down the line in program execution, causing bugs that may be [[Heisenbug|sporadic]] and/or difficult to track down.  Programmers sometimes use a similar VERIFY(X) define to alleviate this problem.

Modern compilers may issue a warning when encountering the above code.<ref>{{Cite web|url=https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wparentheses-367|title=Warning Options (Using the GNU Compiler Collection (GCC))}}</ref>