Differences

This shows you the differences between two versions of the page.

--- principles:fail_fast [2021-09-02 12:02] – old revision restored (2021-05-19 11:17) 65.21.179.175
+++ principles:fail_fast [2021-10-18 21:33] (current) – +++ restored +++ christian
@@ Line 1: / Line 1: @@
-====== Fail Fast [see Rule of Repair] ======
+====== Fail Fast (FF) ======
+===== Variants and Alternative Names =====
+  * Rule of Repair((Eric S. Raymond: //[[http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878538|The Art of Unix Programming: Rule of Repair]]//))
+  * Crash Early((Andrew Hund and David Thomas //[[http://pragprog.com/the-pragmatic-programmer/extracts/tips|The Pragmatic Programmer]]//, p. 120))
+===== Context =====
+/* fill in contexts here: */
+  * [[contexts:Implementation]] /* FF is more about implementation than design */
+  * [[contexts:API Design]]
+===== 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, violated invariants, etc. In case of methods this means that it checks for errors and reports them for example by means of throwing an exception.
+===== 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:Proposed]]
+  * [[wiki:Examined]]
+  * [[wiki:Accepted]]
+  * [[wiki:Questioned]]
+*/
+===== Relations to Other Principles =====
+==== Generalizations ====
+==== Specializations ====
+==== Contrary Principles ====
+==== Complementary Principles ====
+  * [[Postel's Law]]: While FF is (amongst others) about checking for erroneous parameters, Postel's Law is about not being too strict with parameters. It says that the design should allow for uncommon or strangely arranged (yet meaningful) input data. This does not contradict FF as Postel's Law does not demand to process meaningless or erroneous data.
+  * [[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't fail when it should, behaves strangely.
+  * [[Murphy's Law]] (ML): Even better than failing fast is to make errors logically impossible. ML is about this.
+==== Principle Collections ====
+{{page>collections:Unix Philosophy (Eric S. Raymond)#Box}}
+{{page>collections:Principles in "The Pragmatic Programmer"#Box}}
+===== Examples =====
+===== Description Status =====
+/* Choose one of the following and comment out the rest: */
+[[wiki:Stub]]
+/*[[wiki:Incomplete]]*7
+/*[[wiki:Complete]]*/
+===== Further Reading =====
+  * Eric S. Raymond: //[[http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878538|The Art of Unix Programming: Rule of Repair]]//
+  * Andrew Hund and David Thomas //[[http://pragprog.com/the-pragmatic-programmer/extracts/tips|The Pragmatic Programmer]]//
+  * [[wiki>FailFast]]
+  * [[wp>Fail-fast]]
+  * Jim Gray: //[[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.110.9127|Why Do Computers Stop And What Can Be Done About It?]]//
+  * Joshua Bloch: //[[http://www.infoq.com/presentations/effective-api-design|How to Design a Good API & Why it Matters]]//
+===== Discussion =====
+Discuss this wiki article and the principle on the corresponding [[talk:principles:Fail Fast|talk page]].
-~~REDIRECT>principles:Rule of Repair~~