principles:fail_fast
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
principles:fail_fast [2021-09-02 12:02] – old revision restored (2021-05-19 11:17) 65.21.179.175 | principles:fail_fast [2021-09-02 12:03] – old revision restored (2021-05-19 11:16) 65.21.179.175 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Fail Fast (FF) ====== | + | ====== Fail Fast [see Rule of Repair] ====== |
- | + | ||
- | ===== Variants and Alternative Names ===== | + | |
- | + | ||
- | * Rule of Repair((Eric S. Raymond: //[[http:// | + | |
- | * Crash Early((Andrew Hund and David Thomas // | + | |
- | + | ||
- | ===== Context | + | |
- | /* fill in contexts here: */ | + | |
- | * [[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 ===== | + | |
- | + | ||
- | Then 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. | + | |
- | + | ||
- | + | ||
- | ===== 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> | + | |
- | {{page> | + | |
- | + | ||
- | ===== Example ===== | + | |
- | + | ||
- | + | ||
- | ===== 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: // | + | |
+ | ~~REDIRECT> |
principles/fail_fast.txt · Last modified: 2021-10-18 21:33 by christian