Comparison
Defensive programmingvsFail-safe
Defensive programming
you added a null check for a case the caller promised could never happen, and it happened.
Writing code that survives inputs and states it believes to be impossible. It is right at trust boundaries, where the caller cannot be trusted, and it is expensive everywhere else: checks in the interior hide bugs, complicate reading and multiply the paths under test. The senior version of this argument is about where the boundary is, not about whether to check.
Full entry →Fail-safe
the permissions service timed out, and the system denied everything rather than letting everything through.
Choosing which way a component falls over when it cannot do its job. Fail-safe denies, fail-open allows, and each is correct in different places — an authorisation check should fail closed, a recommendation widget should fail open. The failure to make this choice explicitly is how an outage in a non-critical dependency takes down a checkout, and it is one line in a design document that pays for itself.
Full entry →