Decide per failure: recover, propagate, or fail. Only handle an error where you can actually do something useful about it. Otherwise let it propagate to a layer that can.
Catch narrowly. Catch the specific exception you expect, not a blanket catch-all. A broad except hides real bugs and turns a crash into silent corruption.
Never swallow. If you catch, either handle it meaningfully or re-raise with context. Don't except: pass over something that matters. Empty handlers are only OK for genuinely-optional, best-effort side work.
Preserve context. Include what you were doing and the inputs in the message; chain the original cause (don't discard the traceback). The message should tell the next reader how to fix it.
Fail fast on programmer errors (bad state, broken invariants) — crash loudly. Handle gracefully only expected operational errors (network, missing file, bad user input).
Clean up reliably — release resources in finally / context managers / defer, on both the success and failure paths.
Test the failure paths, not just the happy path.

Más de este repositorio

mismo repositorio

Catch bad React in your changes — run react-doctor's deterministic scan and fix what it flags

Run a verifiable security scan (vulns, secrets, misconfig) over code you wrote or deps you added, before calling the work done

Drive a real browser verifiably — navigate, snapshot, act BY INDEX, extract; every step provable

Run multi-agent work as ONE provable causal DAG — parallel subagents, an Orchestrate graph, an immutable spec-seed

Author or connect a Model Context Protocol server so an agent gains new tools

Build automated pipelines that gate merges and ship reliably

name	error-handling
description	Handle failures deliberately — fail loud, recover narrow, never swallow
version	1
trust	built-in

Good error handling makes failures visible and recoverable. The worst bug is the one a bare except hides.

Decide per failure: recover, propagate, or fail. Only handle an error where you can actually do something useful about it. Otherwise let it propagate to a layer that can.
Catch narrowly. Catch the specific exception you expect, not a blanket catch-all. A broad except hides real bugs and turns a crash into silent corruption.
Never swallow. If you catch, either handle it meaningfully or re-raise with context. Don't except: pass over something that matters. Empty handlers are only OK for genuinely-optional, best-effort side work.
Preserve context. Include what you were doing and the inputs in the message; chain the original cause (don't discard the traceback). The message should tell the next reader how to fix it.
Fail fast on programmer errors (bad state, broken invariants) — crash loudly. Handle gracefully only expected operational errors (network, missing file, bad user input).
Clean up reliably — release resources in finally / context managers / defer, on both the success and failure paths.
Test the failure paths, not just the happy path.