| 
|
Topic: defensive programming
topics >
computer science >
software maintenance
Group:
Thesa programming system
Topic:
consistency testing
Topic:
error checking in robot programming
Topic:
error safe systems
Topic:
preventing accidental errors
Topic:
range checking
Topic:
reliability of distributed systems
Topic:
resourceful, redundant systems for reliability
Topic:
safety critical systems
Topic:
self-identifying data structures
Topic:
sensitivity of software to change
Summary
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: fault containment
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: avoid misuse
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: autosave
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: auto-correct data
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: defensive programming not needed
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]
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
[»maguS_1993]
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)