Availability Guide for Application Design

Minimizing Programming Errors
Availability Guide for Application Design—525637-004
9-6
Checklist for Detecting Errors
An eye-catcher is a text string or other constant value placed in a critical data
structure. Your program can check that the data structure contains the text string to
increase confidence that the data structure is valid. If, for example, some other part
of your program or some other program executing privileged code has overwritten
the data structure, then the eye-catcher will not contain the expected value, and
your program can take appropriate action.
Coupled with object-oriented programming or structured programming techniques,
it is easy to perform this check because only one object or routine will be
accessing the data structure. This object or routine can make one simple test
before performing a read or write operation against the data structure and
determine that the data structure is valid.
•
Change the eye-catcher to an invalid value when the data structure is deallocated.
Following this rule ensures that dangling pointers that access deallocated
structures are detected on their first occurrence.
•
Perform periodic checks of sets of data structures.
You can periodically sweep through a set of data structures making checks, for
example, to make sure that the forward and backward pointers in a doubly linked
list agree at each list element.
The period of the sweep is a compromise between how much overhead you are
prepared to accept and the maximum time it would take to report an error if this
kind of error occurred.
•
Check the range of all input variables.
An unexpected value probably indicates an error in the calling module.
•
Check for uninitialized pointers and null pointers.
A pointer that has not been initialized is likely to contain garbage. Note that even in
a type-safe language, such as C++, it is possible to pass a null pointer rather than
a pointer to an element of a class.
•
Check for error returns whenever applicable.
Unexpected values probably indicate an error in the returning module. Never
assume that a procedure cannot fail. If an error code is part of that procedure’s
interface, then it might fail in the next release, even if it does not do so today.
•
Check for infinite loops.
A counter placed somewhere within a loop can be set to trigger an alarm on
reaching a value that indicates that the loop is infinite. The SETLOOPTIMER
procedure can be used for this for multithreaded programs and some loop
constructs.
•
Check that counters increment correctly.