Claude Code Error Handling: What to Ask For and What to Skip

Left to its own defaults, Claude will wrap nearly everything in try-catch. It'll add null checks for values that can't be null. It'll handle errors that can never happen given the types. The code looks defensive. It's actually noise.

Here's how I get error handling that's actually useful.

Tell Claude which errors matter

The generic "add appropriate error handling" prompt produces generic error handling. What works better is being specific about what can go wrong:

Add error handling for:
- Network timeouts on the fetch call
- Malformed JSON in the response
- Missing required fields in the parsed data
Do NOT add error handling for null checks on values
that are guaranteed by the TypeScript types.

Claude follows this well. The result is handling for real failure modes instead of defensive checks for impossible states.

Distinguish fail-fast from degrade-gracefully

These are different strategies and Claude will pick one if you don't specify. For a configuration loader that runs at startup, failing fast is correct — you want to know immediately if the config is bad. For a dashboard widget fetching non-critical data, graceful degradation is right — show a fallback, log the error, don't break the page.

Adding "this should fail fast" or "this should degrade gracefully and return a default value" to your prompt changes the output meaningfully.

The pattern Claude gets wrong most often

Catching errors and re-throwing them with no added information:

try {
  return await fetchData(url)
} catch (error) {
  throw error  // pointless
}

Or catching errors and swallowing them silently:

try {
  await saveRecord(data)
} catch (error) {
  // silent failure
}

Both of these make debugging harder. The first adds nothing. The second hides failures. Claude produces both when it's filling in structure without thinking about what the caller needs to know.

Ask explicitly: "If this fails, what should the caller know about why?" That question forces Claude to think about the error contract, not just the syntax.

Error messages as documentation

Claude writes error messages like: "An error occurred." or "Invalid input." These are useless in production logs.

Ask for: "Include the input value and the expected format in the error message." The output becomes: "Invalid date format: received '13/45/2026', expected 'YYYY-MM-DD'." That's debuggable.

When to delete Claude's error handling

If I see any of these, I delete them without asking:

• Null checks on typed values that can't be null
• Try-catch that just re-throws with no transformation
• Error handlers that only log "something went wrong"
• Checks for impossible states just because they look defensive

Error handling that doesn't handle anything is just code that makes readers think the code is more robust than it is.