HIGHQualitysmallError Handling

Fail fast and handle errors at boundaries

Let errors propagate up to a well-defined boundary (request handler, route, job runner) instead of catching them mid-flow. Centralizing handling keeps core logic clean and recovery consistent.

Why This Matters

Scattered try/catch deep in business logic produces inconsistent recovery and partially-applied state changes that are hard to reason about.

Related Rules

Use Error Boundaries

Quality

HIGH

Log Errors with Context

Quality

HIGH

Never silently swallow errors

Quality

HIGH

Narrow caught errors and rethrow what you can't handle

Quality

MEDIUM

Catch this automatically on every PR

BeforeMerge scans your pull requests against this rule and dozens more. Get actionable feedback before code ships.

Join Waitlist Browse All Rules

Why this matters

Catching errors in the middle of business logic forces every function to decide how to recover, leading to duplicated and inconsistent handling. Instead, fail fast: validate inputs early, throw on invalid state, and let the error bubble to a single boundary (API handler, server action, queue worker) that knows how to respond.

// Bad — every layer guesses at recovery
function parseConfig(raw) {
  try { return JSON.parse(raw); } catch { return {}; } // hides bad config
}
 
// Good — fail fast; boundary maps to a response
function parseConfig(raw: string) {
  return JSON.parse(raw); // throws on invalid input
}
 
// boundary
export async function POST(req: Request) {
  try {
    const cfg = parseConfig(await req.text());
    return Response.json(await run(cfg));
  } catch (err) {
    return toErrorResponse(err);
  }
}