Fail loudly, fail early

Why this rule exists

A failure you can see is a failure you can fix. When code swallows errors or limps along in a corrupted state, the real problem surfaces later, far from its cause, wearing a disguise. Failing early keeps the distance between the fault and the symptom short, which is the single biggest factor in how long a bug takes to find.

In practice

Validate inputs at the boundary and throw or return an error the moment an assumption breaks. Prefer a loud crash on startup over a silent misconfiguration that corrupts data for a week. Do not catch an exception unless you can actually handle it; a bare catch that logs and continues is usually hiding the bug you will chase next month.

Example

function getUser(id) {
  try { return db.find(id); }
  catch (e) { return null; } // caller can't tell
}

function getUser(id) {
  if (!id) throw new Error('getUser: id required');
  return db.find(id); // let real failures surface
}

When it doesn't apply

Systems at a trust boundary — request handlers, batch jobs, plugins — should contain failures rather than crash the whole process. There, catch at the top, isolate the blast radius, and keep serving other work.