Availability Guide for Application Design

Minimizing Programming Errors
Availability Guide for Application Design—525637-004
9-5
Checklist for Detecting Errors
•
Are all related data structures updated on the occurrence of an event?
•
Are all related processes notified about the occurrence of an event?
•
Are there potential race conditions between vulnerable time windows?
•
Are possible hardware errors or timeout situations properly handled?
•
Are all error-handling paths testable?
•
Is there protection against invalid parameters on procedure calls?
•
Can software operate on all possible combinations of system, peripheral, and
network states?
•
Can software operate in a full range of workload or resource usage?
•
Are variable names correct?
•
Are the values of constants correct?
•
Is arithmetic overflow possible?
•
Do code changes affect compatibility between software versions?
•
Do calls to Debug or the Inspect product exist in production code?
•
Are all related procedures updated on a code change?
•
Can a sequence of normal events cause a halt due to a halt assertion?
•
Are there potential exception conditions that are not being handled? Are these
documented?
•
Are there data structures that are not protected by eye-catchers or other forms of
data walls? Are they protected by another mechanism? Are they documented?
Checklist for Detecting Errors
The following list provides a starting point for inserting detectors to catch unanticipated
errors in your code. Throughout code development, these error detectors will help you
get bugs out of your code. Once the code goes into production, these error detectors
remain in the code and can help minimize the immediate effect of errors by triggering
alarms that enable human or automated operators to respond quickly to the problem,
and ultimately lead to error correction by simply highlighting the fact that a coding error
exists.
Of course, no such list can identify the error detection needs of every program in every
application. You will need to add to this list, depending on the specific needs of each of
your software modules.
•
Set eye-catchers in your data structures as you allocate them and check for the
eye-catcher on each access.