Fail Fast Principle
debt(d7/e3/b5/t5)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints list phpstan and psalm as tools, but these static analysers can flag some patterns (e.g. unhandled nulls) yet cannot reliably detect the full range of fail-slow patterns — swallowed exceptions, silent null returns used as error signals, or the @ operator suppression — without careful configuration and human review. Many violations slip through to runtime testing.
Closest to 'simple parameterised fix' (e3). The quick_fix is conceptually a one-liner (throw instead of return null/false), but the common_mistakes show multiple patterns spread across constructors, catch blocks, and error-suppression sites. Each individual fix is small, but systematically replacing all fail-slow patterns across a component requires a small, targeted refactor rather than a single-call swap.
Closest to 'persistent productivity tax' (b5). Failing to apply fail-fast principles applies across web, cli, and queue-worker contexts and affects how errors propagate throughout the entire codebase. Silent failures and invalid state propagation slow down debugging and maintenance across many work streams, imposing an ongoing productivity tax, but it doesn't fully reshape every architectural decision.
Closest to 'notable trap' (t5). The misconception field documents the canonical wrong belief precisely: developers conflate fail-fast with crashing aggressively on any error, when it actually means detecting and reporting invalid state close to the source. This is a documented, commonly learned gotcha — serious enough to cause misapplication, but not so perverse that it contradicts a concept from a completely different domain.
Also Known As
TL;DR
Explanation
Failing fast means: validate inputs immediately on entry, throw exceptions rather than returning error codes that callers may ignore, assert invariants at the start of methods, and surface configuration errors at startup rather than at runtime. The alternative — letting invalid state propagate — produces hard-to-debug failures far from the root cause. In PHP, strict types, guard clauses, and early throws implement fail-fast behaviour at the language level.
Common Misconception
Why It Matters
Common Mistakes
- Returning null or empty values on failure instead of throwing an exception — callers silently pass invalid state downstream.
- Not validating constructor arguments — allows objects to be constructed in an invalid state.
- Catching exceptions and retrying silently without limit — turns a fast fail into a slow, silent hang.
- Suppressing errors with @ operator — PHP's most notorious fail-slow pattern.
Code Examples
function process(array $data): Result {
if (isset($data['user'])) {
if ($data['user']['age'] >= 18) {
if (!empty($data['user']['email'])) {
// actual work buried in nesting
}
}
}
}function process(array $data): Result {
if (!isset($data['user'])) throw new \InvalidArgumentException('user required');
if ($data['user']['age'] < 18) throw new UnderageException();
if (empty($data['user']['email'])) throw new \InvalidArgumentException('email required');
// happy path — no nesting
}