Opening the book…
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.
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.
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
}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.