This is an old revision of the document!
A design is better when fails fast, i.e. as soon as an unrepairable erroneous condition is encountered.
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.
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.
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.
|Principles In "The Pragmatic Programmer"|
|Don't Repeat Yourself||Make It Easy To Reuse||Eliminate Effects Between Unrelated Things||Program Close To The Problem Domain||Keep Knowledge in Plain Text||Write Code That Writes Code|
|Crash Early||Use Assertions to Prevent the Impossible||Use Exceptions for Exceptional Problems||Finish What You Start||Minimize Coupling Between Modules||Configure, Don't Integrate|
|Put Abstractions In Code, Details In Metadata||Always Design for Concurrency||Separate Views From Models||Abstractions Live Longer than Details|
Discuss this wiki article and the principle on the corresponding talk page.