assert.h

What does /prog/ think about assertions?

By example, suppose you are developing a library, and you have a function like this:

/** Serves the foo.
 *
 * @param request The request id, which must be an odd number.
 */
int foo (int request);

Obviously you should implement some kind of checking in order to avoid bad jokes during execution, so you may be tempted to do something like

#include <assert.h>

int foo (int request)
{
    assert(request % 2);
    ...

I think this is a good design, since it makes the API more simple and it doesn't need an error management procedure. Obviously this is not the case when the error depends on - say - the content of a file, which may be non-deterministic.

The drawback is of course the crash of the whole application, but this is responsability of the developer who's using the library, since the documentation prohibits to insert even values as parameter of the foo function.

What do you think?

I usually use assert to verify the status of internal variables, that no user of the library could ever modify - class invariants and the like. For function call parameters, I just throw WTFAreYouDoingExceptions or something along those lines (something recoverable, anyway), unless the code is performance critical in which case asserts that compile away are a better choice.