Failure is an explicit unsuccessful outcome: an operation cannot fulfill its intended result, may complete only partly, or may return a recovery result such as cached data. Code should define success and failure early, make failure visible rather than silent, and release files, connections, sockets, and other resources on either path. section 2.5
Graceful failure handling is a design concern, not a patch added after the happy path. It protects robustness, leaves useful clues for diagnosis, preserves readable control flow, and avoids exposing users to mishandled errors. section 7.0 section 7.3
Choose the response by first identifying the kind of failure:
- Business logic errors are expected violations of rules or usage constraints. Anticipate them, validate early, and guide the user back to a safe path. section 7.1.1 section 7.3
- Technical problems arise from infrastructure or external dependencies, such as storage, databases, email, networking, or configuration. Do not leak raw technical details across UI or client boundaries; translate them into meaningful controlled responses while preserving the cause for diagnosis. section 7.1.2 section 7.3
- Programming errors are code defects to correct during development. Fatal errors compromise process stability and generally call for code or infrastructure fixes, or a fail-fast response, rather than in-process recovery. section 7.3 section 7.1.4
A user takes an unexpected path
Invalid form input, an expired discount code, an unsupported upload, a duplicate email address, and too many login attempts are business-rule failures. Treating these as anticipated paths lets the application explain the situation and help the user proceed, rather than leaving an infinite spinner or an incomprehensible stack trace. section 7.1.1
Keep failure paths narrow and readable. Avoid generic catches without a clear reason; log only when it adds diagnostic value, with useful context and no sensitive data. A failure report should then be clarified into reproducible conditions before conclusions or fixes are attempted. section 7.3 section 10.3.2
Table 7.1 Summary of failure types and handling strategies
|
Type of failure
|
Description
|
|---|---|
|
Business logic errors
|
Violations of business rules or expected usage constraints that the system must anticipate and communicate clearly
|
|
Technical problems
|
Failures caused by external systems, infrastructure, configuration, or unavailable technical dependencies
|
|
Programming errors
|
Defects in the code itself caused by incorrect logic, invalid assumptions, or broken invariants
|
|
Fatal errors
|
Critical runtime failures that compromise process stability and usually prevent normal recovery
|
Compare the four failure categories, their sources, and the broad handling direction before deciding whether to validate, translate, fix, recover, or fail fast. section 7.1.4
