In focussing on the main logic of a program, programmers
may fail to take into account abnormal situations,
such as invalid data input, or a hard disk
becoming full. As a result, their programs are vulnerable to unexpected events or
conditions. In essence, such programs have holes in their defenses.
In particular, interfaces between programs are some of the
most error-prone areas in a system. One often-cited study
found that 39% of all software errors were internal interface
errors, i.e., errors in communication between programs.
Clearly to ensure more robust programs, we need not only
to protect ourselves from our own mistakes, but also to isolate
our programs from the potential errors of others. We
refer to this approach as Defensive Programming.
There are various causes of program malfunction that we can defend against:
- DP-1: Parameter Not Checked
A parameter received by a program is used without first checking if its contents are present and within the expected range.
- DP-2: Status Ignored After Call
Error status codes or exceptions from the run-time environment are suppressed or ignored, masking internal processing errors.
- DP-3: Unexpected State Not Trapped
Part of a program that uses a value to switch between different branches does not trap unexpected cases.
- DP-4: Unused Variables
There are unreferenced variables in the code. Unreferenced variables are a strong indicator for other errors.
- DP-5: Information Exposed
Information internal to a module has been made available to other modules. The practice of information hiding makes it much easier to modify large programs.
|
More Defect Categories:
|
Defect Indicators for
"Defensive Programming":
|
