Differences

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

--- principles:fail_fast [2013-02-18 17:24] – external edit 127.0.0.1
+++ principles:fail_fast [2021-10-18 21:33] – old revision restored (2015-11-12 20:13) christian
@@ Line 24: / Line 24: @@
 ===== 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.
+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.
@@ Line 36: / Line 36: @@
 ===== Caveats =====
-See section [[#contrary principles]].
+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]].
@@ Line 71: / Line 73: @@
 {{page>collections:Principles in "The Pragmatic Programmer"#Box}}
-===== Example =====
+===== Examples =====
@@ Line 89: / Line 91: @@
   * 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]].