Claude Code error handling: what to ask for and what to delete

Left to its defaults, Claude wraps nearly everything in try-catch. Null checks for values that can't be null. Handlers for errors that can never happen. The code looks defensive. It's actually noise.

Tell Claude which errors actually matter

The generic "add appropriate error handling" prompt produces generic error handling. What works better:

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 null checks for values guaranteed by the TypeScript types.

Claude follows this well. You get handling for real failure modes instead of defensive checks for impossible states.

Fail-fast vs degrade-gracefully

These are different strategies and Claude will pick one if you don't specify.

For a config 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" changes the output meaningfully.

The patterns Claude gets wrong most often

Catching and re-throwing with no added information:

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

Or catching and swallowing silently:

try {
  await saveRecord(data)
} catch (error) {
  // nothing
}

Both make debugging harder. Ask explicitly: "If this fails, what should the caller know about why?" That forces Claude to think about the error contract.

Error messages as documentation

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

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

When to delete Claude's error handling

• Null checks on typed values that can't be null
• Try-catch that just re-throws unchanged
• Error handlers that only log "something went wrong"
• Checks for states that are impossible given the types

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

---

More Claude Code patterns at builtbyzac.com