Fail Fast

When something happens that should be impossible, stop immediately and visibly rather than continuing in a corrupted state. A dead program tells no lies: crashing early surfaces the defect at its source instead of letting it propagate into confusing, distant failures.

Why it Matters

A program that limps on after an impossible condition does more damage and hides the real cause. Failing fast turns a silent, spreading corruption into a loud, local signal that points straight at the bug, which is far cheaper to diagnose.

Signals

• Defensive code that swallows impossible conditions and continues.
• Bugs that surface far from their cause, after the bad state has spread.
• "It mostly works" with occasional inexplicable corruption.

Benefits

Defects caught at their origin, smaller blast radius, and clearer diagnosis. Assertions and early crashes encode what the program assumes to be true.

Risks

Crashing on conditions that are actually recoverable degrades reliability; fail fast applies to "can't happen" violations, not to expected, handleable situations. In user-facing or safety-critical paths, failing fast must be paired with graceful recovery at the boundary.

Tensions

Directly competes with Define Errors Out of Existence and with tolerant, recoverable designs: one says crash on the impossible, the other says redefine conditions so they are not errors. The resolution is the nature of the condition: surface genuine "impossible" states loudly; design away the merely inconvenient ones.

Examples

Asserting an invariant and aborting when it is violated instead of patching the value and continuing; validating at a boundary and rejecting rather than processing malformed input as if it were valid.