Violated precondition errors involve failures to follow the programming rules set out by the Essential Math Module classes. If an indexing operator says not to ask for an index greater than a vector's length and you do so anyway, that is a violated precondition.

A more formal description is given by Meyer (1988). In summary, Meyer says that a function is regarded as a contract between the caller and the callee. If the caller abides by a set of preconditions, then the callee guarantees to return results that satisfy a set of postconditions. Typically, preconditions are such things as requiring that an index be within a set of bounds, that pointers be non-nil, and so on. The ideal goal is that these types of errors never happen. If they never happen, there is no need to provide a recovery mechanism or even to detect them!

But, of course, they do happen. So, how do you guard against them? And how do you detect them? The Rogue Wave classes have an extensive set of PRECONDITION and POSTCONDITION clauses at the beginning and end of critical functions. They can be activated by compiling the entire library with the preprocessor flag RW_DEBUG defined.

If compiled with the RW_DEBUG flag defined, the resultant library will be slightly larger and slightly slower. See the appropriate makefile for additional directions.

The preconditions and postconditions are implemented either through the Rogue Wave error facility or with asserts. With asserts, a failure causes the offending condition to be printed out, along with the file and line number where it occurred.

Again, the assumption is that these are programming errors and can and should be avoided. Hence, there are no facilities for error recovery.