casacore
|
#include <Assert.h>
Public Member Functions | |
assert_ (int expr, const char *msg) | |
assert_ (const void *ptr, const char *msg) | |
assert_ (int expr, const char *msg, const char *file, Int line) | |
assert_ (const void *ptr, const char *msg, const char *file, Int line) | |
void | null () |
A no-op, but it keeps g++ from complaining about "variable not used" errors. More... | |
Utility class for Assert macros.
Public interface
Templated class assert_
is the basis for the macros DebugAssertExit
, DebugAssert
, AlwaysAssertExit
, and AlwaysAssert
which form the "public interface" to the Assertion mechanism.
The present Assertion mechanism uses the exception handling mechanism to throw the errors when an Assertion fails. It can be used in two ways:
DebugAssertExit(expr)
AlwaysAssertExit(expr)
expr
evaluates to a null value. This form is intended for the end users because presumabily at their level there is no way to recover from errors. DebugAssert(expr, exception)
AlwaysAssert(expr, exception)
expr
is null. This form is designed to be used by library elements because it actually raises an exception which can be later caught in the regular way.
Tip: DebugAssertExit
and DebugAssert
are only invoked in debug mode (i;e; when AIPS_DEBUG
is defined); otherwise they preprocess to null statements; AlwaysAssertExit
and AlwaysAssert
are always invoked;
Tip: Class assert_
is internal to the Assertion mechanism and should be undocumented; However, documenting the class is the only way to document this mechanism, which for the rest consists of preprocessor macros;
The implementation of the Array classes contains many examples of the Assertion mechanism. The following application of the Assertion mechanism is taken from the archive of the aips2 mail group (Brian Glendenning, 1994/03/23): -wor kers@ nrao .edu
I thought I'd readvertise a technique I use that helps me find problems in the classes I write. I have found this to be an EXTREMELY useful way of discovering bugs automatically (so the users of your class don't have to manually).
In your class, write an ok()
member function that returns a Bool
. Allow for inheritance and make it a virtual function (in fact, the derived class's ok()
would probably call the ok()
from its parent, as well as doing specific stuff for the derived class).
Then in every member function, place a call to ok()
in an Assertion. Like this:
The second argument is the exception you want to throw. AipsError
will always do, although you can throw a more particular one if you want to. This Assertion will not be in production code – i.e. if AIPS_DEBUG
is not defined, the above line will be a null statement. I place these lines at the entry to all member functions (except I place them at the end of a constructor!). (I normally don't put an Assertion in an inline function).
In the ok()
function you should Assert a class's invariants. This is more or less the same as Asserting that an object's private and protected data are consistent. For example, one of the simple tests I do in the array classes is Assert that the number of elements (which I cache) is indeed equal to the product of its shape (I do ~15 tests in the ok()
for the new Array<T>
class).
|
inline |
|
inline |
casacore::assert_< t >::assert_ | ( | int | expr, |
const char * | msg, | ||
const char * | file, | ||
Int | line | ||
) |
casacore::assert_< t >::assert_ | ( | const void * | ptr, |
const char * | msg, | ||
const char * | file, | ||
Int | line | ||
) |
|
inline |