defensive

Defensive Programming: Never Trust the Input

Software fails because something arrived that the code did not expect. A null where an object was assumed, a string where a number was assumed, a value outside the range the arithmetic relies on, a service that returned an error instead of a payload.

The defensive discipline is to assume none of it. Every function treats its callers as unreliable, every boundary is checked, every external call is wrapped, and every failure path has a defined behaviour rather than an exception escaping into the user's face.

The line that does most of the work:

An unhandled failure is a defect you shipped to the user. A handled failure is one you chose the behaviour for. Wherever your code touches something it did not construct, decide now what happens when that thing is wrong, because the alternative is finding out in production.

The five disciplines

Validate at every boundary. Any value crossing into your code from elsewhere is untrusted: HTTP requests, config files, environment variables, database rows, other modules' return values. Check type, range, shape and required fields before use. Validation duplicated at several layers is not waste; it is depth, and it means one missed check does not become a defect.

Guard against absence. Null, undefined, empty string, empty list, missing key and zero are all values a caller can hand you. Check for them explicitly before dereferencing, and decide what absence means here: an error, a skip, or a default.

Supply safe fallbacks. When a value is missing or invalid, prefer continuing with a sensible default over aborting. A report that renders with a zero in one cell serves the user better than a stack trace. Choose the default that fails toward the least harm.

Catch, log, continue. Wrap operations that can throw. Log enough context to diagnose it later: the inputs, the operation, the error. Then decide whether this frame can proceed. An exception that escapes several frames loses the context that would have explained it.