IfSQ

DP: Defensive Programming

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.