The ErrorLogger package provides a header ErrorLogger/ELassertN.h, that defines macros such as ELassert3(condition) and ELwarningAssert2(condition). These behave like the assert macro but permit gradations of activation, and also route the output (when triggered) to errlog, either with severity ELabort or severity ELwarning.

Purpose and Rationale

Using Graded Asserts Connecting to the ErrorLogger: ELassertN.h

Purpose and Rationale

The granularity of the C assert mechanism is inadequate for some purposes. Every assert() macro is active unless NDEBUG is not defined, and disappears if NDEBUG is defined. For some assertions this is appropriate. However, the coder may well know that some specific assertions are unlikely to become time critical, and ought to remain active even though some degree of optimization has been specified.

The mechanism we use to address this obeys the following rules:

1. The standard assert mechanism, activated by lack of NDEBUG, continues to behave as in the standard manner, except for a different mode of aborting when an ELassert assertion fails.
2. When an ELassert fails, instead of writing to cerr and calling exit(), it will issue a message to errlog, of severity ELabort, containing the text of the assertion and the file and line of the failed assertion.
3. There are several new assert-like macros, such as ELassert1. If any of these are triggered, the behavior is the same as when an ELassert is triggered.
4. The activation of the new assert-like macros is again controlled by defines. The gradations of asserts will be reflected in the gradations of available defines; for example ELassert1 is de-activated if NDEBUG, NDEBUG1, or NDEBUG2 is defined.
5. The new assert-like macros, in the case where they are not activated, preprocess down to no code at all ,so that there is no question of removing them "just in case the optimizer isn't that good."

A discussion of the reasoning behind this is available.

There is also a mechanism for declaring assertions that only generate warnings if triggered, allowing a framework wants to continue processing in some manner despite a failed (user) assertion. These are analogous to the corresponding ELasserts but with names like ELwarningAssert1.

Using Graded Asserts Connecting to the ErrorLogger: ELassertN.h

(This header is part of the ErrorLogger package, since these macros cannot be used if that package is not in use.)

Having included ErrorLogger/ELassertN.h, one can use the following macros with the same semantics as assert():

• ELassert3 (condition) -- for assertions that are to be most readily deactivated.
• ELassert2 (condition) -- for assertions that will often be deactivated but can remain active when assert3 is inactive.
• ELassert1 (condition) -- for assertions which are more persistent than assert2, but can be deactivated without deactivating ordinary asserts,
• ELassert (condition) -- the ordinary assert, controlled by NDEBUG (only triggering an ELabort severity mesasage to errlog when the assert fails).
• sanityCheck (condition) -- for assertions controlled by a separate define, NOSANCHECK; these can remain active even if NDEBUG is defined.

The macros are controlled by symbols as follows:

• ELassert3 (condition) -- deactivated by defining NDEBUG, NDEBUG1, NDEBUG2, or NDEBUG3.
• ELassert2 (condition) -- deactivated by defining NDEBUG, NDEBUG1, or NDEBUG2.
• ELassert1 (condition) -- deactivated by defining NDEBUG or NDEBUG1.
• ELassert (condition) -- corresponding to the ordinary assert, controlled by NDEBUG.
• ELsanityCheck (condition) -- controlled by NOSANCHECK.

An example code snippet:

#include "ErrorLogger/ELassertN.h"
int transform(int);
bool testIfValid(int);
int i = transform(0); 
ELsanityCheck (testIfValid(i)); // Not time critical
for (i = 0; i < 100; i++) {
  int j = transform(i);
  ELassert (testIfValid(j));    // Normally active; off if NDEBUG is defined
  for (int k = 0; k < j; k++) {
    int m = transform(k);
    ELassert3 (testIfValid(m)); // Inactive when any NDEBUGn is defined
  }
}

If one of these macros is triggered, an error message is issued, with severity ELabort. This recommends that the program exit after outputting the error information. (The framework may be set up so as to ignore that recommendation.)

Assertions Issuing Warnings

This can be used, for instance, if there is some difficult optimization which would be appropriate to implement if some condition is not super-rare; so you may wish to test for that condition during the first part of production running, but not to abort the jobs where it is detected.

• ELwarningAssert3 (condition) -- deactivated by defining NDEBUG, NDEBUG1, NDEBUG2, or NDEBUG3.
• ELwarningAssert2 (condition) -- deactivated by defining NDEBUG, NDEBUG1, or NDEBUG2.
• ELwarningAssert1 (condition) -- deactivated by defining NDEBUG or NDEBUG1.
• ELwarningAssert (condition) -- corresponding to the ordinary assert, controlled by NDEBUG.
• ELwarningCheck (condition) -- controlled by NOSANCHECK.