Topic: defensive programming

topics > computer science > Group: programming

software maintenance
Thesa programming system

consistency testing
error checking in robot programming
error safe systems
preventing accidental errors
range checking
reliability of distributed systems
resourceful, redundant systems for reliability
safety critical systems
self-identifying data structures
sensitivity of software to change


Defensive programming is assuming a hostile environment for code and handling contingencies that may arise. Defensive programming is important because nonsensical execution can cause arbitrary damage to any module. Defensive programming contains the error to the module that first detected the error. It may then forward the error to a caller. The goal is to place the code in a straight-jacket that prevents deviate behavior.

Defensive programming is particularly important in user interfaces. Users tend to respond to errors and uncertainty with action. They defer error correction if possible. Dialogs can tolerate spelling errors, alternative formats, and missing data. All actions should be safe and reversible. Edits can be saved continually. Inconsistent data can be marked for checking later.

Data structures should be self-checking and self-correcting. For example, disk blocks can contain sufficient data to restore directory information. File systems should contain enough redundant data to limit the damage of lost blocks.

Data structures can be designed to survive memory errors. Most programs may detect such errors but few attempt to correct them. If memory errors are likely, error detection codes may be used to automatically correct the errors.

Defensive programming should report detected errors. If so, some other error that caused the failure will go undetected. Defensive programming should not attempt to be perfect. It should catch errors fairly soon after they occur. But defensive programming is important even in fully typed checked programs. There are too many possible sources of error to justify pretending that errors can not occur. (cbb 4/98)

Subtopic: nonsensical execution up

Quote: nonsensical execution causes arbitrary damage; may not effect program behavior until much later [»stroRE1_1986]
QuoteRef: sattEH5_1975 ;;4 assumes no part of program error-free.

Subtopic: fault containment up

Quote: bookkeeping information for a UNIX cylinder group is staggered to prevent a lost platter from destroying everything [»mckuMK8_1984]
Quote: fault containment is the reduction and elimination of error propagation
Quote: layered systems should prevent errors from spreading to other layers [»abboRJ3_1990]
Quote: system components should be self-protective and self-checking to prevent error propagation [»abboRJ3_1990]
Quote: a self-checking component can propagate some errors if its clients can catch the error [»abboRJ3_1990]

Subtopic: avoid misuse up

Quote: users tend to respond to errors and uncertainties with action; often defer error correction advice; results in a series of mistakes [»carrJM9_1988]
Quote: should design dialogues to prevent or tolerate errors; e.g., alternative telephone number formats; widely ignored [»moliR3_1990]
Quote: software should not be easy to misuse
Quote: a system needs to store input conditionally; e.g., an input form with a misspelling goes to the suspect-orders file [»moreDV7_1983]

Subtopic: autosave up

Quote: KMS automatically saves changes when leaving a frame [»akscRM7_1988a]
QuoteRef: sammJE_1969 ;;689 autosave parameters option-- back's up user's work periodically auto

Subtopic: auto-correct data up

Quote: should design data structures so that erroneous data does not interfere with processing of good data [»jackMA_1975]
Quote: a doubly-linked list with back pointers to node before last is 3-detectable and 1-correctable [»taylDJ11_1980]
Quote: threaded binary tree for detection and correction of errors: link null-pointers in a special way [»taylDJ11_1980, OK]
Quote: with parity and memory correction, a bad bit in memory does not break a machine [»liskB10_1981]

Subtopic: defensive programming not needed up

Quote: don't live with broken windows; fix bad decisions and poor code; isolate if not enough time [»huntA_2000]
Quote: defensive programming attempts to catch all problems; often redundant checks; increases complexity [»meyeB10_1992]
Quote: defensive programming not necessary with Eiffel since all preconditions are guaranteed by the client [»meyeB10_1992]
Quote: defensive programming is bad because it hides errors that should never happen [»maguS_1993]
Quote: a meaningless or erroneous argument should be illegal, otherwise you hide bugs rather than find them

Related Topics up

Group: software maintenance   (14 topics, 368 quotes)
Group: Thesa programming system   (11 topics, 561 quotes)

Topic: consistency testing (60 items)
Topic: error checking in robot programming (6 items)
Topic: error safe systems (76 items)
Topic: preventing accidental errors (37 items)
Topic: range checking (20 items)
Topic: reliability of distributed systems (35 items)
Topic: resourceful, redundant systems for reliability (38 items)
Topic: safety critical systems (32 items)
Topic: self-identifying data structures (18 items)
Topic: sensitivity of software to change
(44 items)

Updated barberCB 5/04
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.