Dead Programs Tell No Lies (Crash Early)

Key Insight

Detecting problems as early as possible is crucial, as continuing with a compromised state can lead to severe damage, such as writing corrupted data or causing infinite loops in machinery. The principle of 'Crash Early' advocates for immediate termination when an 'impossible' situation occurs, rather than attempting to recover or ignore errors. This approach stems from the understanding that a program discovering a state it deems impossible is no longer viable, and any subsequent actions become suspect.

This philosophy is deeply ingrained in languages like Erlang and Elixir, where programs are designed to fail but failures are managed by supervisors. A supervisor runs code and handles its failures by cleaning up or restarting, forming supervisor trees for cascading fault tolerance, making these languages suitable for high-availability systems. In other environments, while direct exit might be too abrupt, the core principle remains: terminate as soon as possible, as a dead program typically causes less damage than a crippled one that continues to operate incorrectly.

Developers should avoid the 'it can't happen' mentality regarding errors; every error provides valuable information. The practice of 'catch and release' for exceptions—catching, logging, then re-raising—is discouraged as it couples code tightly to specific exceptions and clutters application logic. A more pragmatic approach is to allow exceptions to propagate automatically. Crashing early, potentially facilitated by assertions or Design by Contract mechanisms, provides more accurate and immediate problem diagnosis, such as `sqrt_arg_must_be_positive` instead of propagating `NaN` errors that manifest much later.