principles:fail_fast
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
principles:fail_fast [2021-09-02 12:03] – old revision restored (2021-05-19 11:16) 65.21.179.175 | principles:fail_fast [2021-10-18 21:33] – old revision restored (2015-11-12 20:13) christian | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Fail Fast [see Rule of Repair] | + | ====== Fail Fast (FF) ====== |
- | ~~REDIRECT> | + | ===== Variants and Alternative Names ===== |
+ | |||
+ | * Rule of Repair((Eric S. Raymond: // | ||
+ | * Crash Early((Andrew Hund and David Thomas // | ||
+ | |||
+ | ===== Context ===== | ||
+ | /* fill in contexts here: */ | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
+ | |||
+ | |||
+ | ===== Principle Statement ===== | ||
+ | |||
+ | A design is better when fails fast, i.e. as soon as an unrepairable erroneous condition is encountered. | ||
+ | |||
+ | |||
+ | ===== Description ===== | ||
+ | |||
+ | Check for erroneous conditions like wrong parameter values, unmet preconditions, | ||
+ | |||
+ | |||
+ | ===== Rationale ===== | ||
+ | |||
+ | When a failure remains undetected, it propagates through the system ultimately causing other modules to fail. This results in in a more complicated fault removal. Furthermore undesired side effects like corrupted files may occur. A crashed program clearly communicates that there is a problem and is often a better situation than a misbehaving program. | ||
+ | |||
+ | |||
+ | ===== Strategies ===== | ||
+ | |||
+ | * Check input parameters for validity -- especially non-nullness. | ||
+ | * Throw an Exception. | ||
+ | * Use assertions. | ||
+ | |||
+ | |||
+ | ===== Caveats ===== | ||
+ | |||
+ | FF reveals problems which are already present in the system. For a system with only a few problems, this is good as the remaining faults are identified and fixed more easily. But applying FF to a system that has many problems may decrease reliability further as problems which were hidden, show up, produce error messages and lead to system aborts. | ||
+ | |||
+ | See also section [[#contrary principles]]. | ||
+ | |||
+ | |||
+ | ===== Origin ===== | ||
+ | |||
+ | |||
+ | ===== Evidence ===== | ||
+ | /* Comment out what is not applicable and explain the rest: */ | ||
+ | /* | ||
+ | * [[wiki: | ||
+ | * [[wiki: | ||
+ | * [[wiki: | ||
+ | * [[wiki: | ||
+ | */ | ||
+ | |||
+ | |||
+ | ===== Relations to Other Principles ===== | ||
+ | |||
+ | ==== Generalizations ==== | ||
+ | |||
+ | ==== Specializations ==== | ||
+ | |||
+ | ==== Contrary Principles ==== | ||
+ | |||
+ | ==== Complementary Principles ==== | ||
+ | |||
+ | * [[Postel' | ||
+ | * [[Principle of Least Surprise]] (PLS): FF is about what a module should do in the case of error. PLS on the other hand is about how the module should behave normally. Furthermore it normally is not a surprise that a module fails when there is an error but a module that doesn' | ||
+ | * [[Murphy' | ||
+ | |||
+ | ==== Principle Collections ==== | ||
+ | |||
+ | {{page> | ||
+ | {{page> | ||
+ | |||
+ | ===== Examples ===== | ||
+ | |||
+ | |||
+ | ===== Description Status ===== | ||
+ | /* Choose one of the following and comment out the rest: */ | ||
+ | [[wiki: | ||
+ | / | ||
+ | / | ||
+ | |||
+ | ===== Further Reading ===== | ||
+ | |||
+ | * Eric S. Raymond: // | ||
+ | * Andrew Hund and David Thomas // | ||
+ | * [[wiki> | ||
+ | * [[wp> | ||
+ | * Jim Gray: // | ||
+ | * Joshua Bloch: // | ||
+ | |||
+ | ===== Discussion ===== | ||
+ | |||
+ | Discuss this wiki article and the principle on the corresponding [[talk: |
principles/fail_fast.txt · Last modified: 2021-10-18 21:33 by christian