prompt GP ChatGPT

Error Handling taste — Claude & Claude.ai prompt: TypeScript error

A prompt that gives an AI assistant the error-handling taste of a TypeScript backend engineer: validate input, split expected errors from bugs, log once, answer with problem+json.

Open on GitHub

What Error Handling taste does

This is a list of opinions about handling errors in a TypeScript backend. Each rule carries a confidence score, so you can see where the author is firm and where he hedges. Validate every external input with a schema library such as Zod before it reaches business logic. Keep expected domain errors apart from unexpected bugs and treat them differently. Define a small set of typed error classes with a stable machine-readable code.

Then come the rules about what to do once you catch something. Catch only where you can add context, recover, or translate the error; let the rest bubble up. Map errors to HTTP responses in one central handler rather than inside each route, and return RFC 9457 problem+json bodies with a code, a human message and a request id. Stack traces, SQL and internal hostnames stay out of client responses.

A third block covers resilience: a timeout on every network call, AbortController to cancel downstream work, a circuit breaker around flaky dependencies, retries only for idempotent operations with exponential backoff and a hard attempt limit. Unhandled promise rejections are treated as fatal. You paste the prompt into a chat as a system instruction or a first message — there is no install step in the usual sense.

What it helps with

validate external input with a schema before business logic
separate expected domain errors from real bugs
define typed error classes with a machine-readable code
move error-to-HTTP mapping into one central handler
put a timeout and cancellation on network calls

Example prompts for the agent

Use these rules as a system instruction and help me handle errors in a TypeScript backend
Review my code against these rules: where do I swallow an error and where is a network call missing a timeout?
Rewrite this catch block so the original error goes into cause and the client gets problem+json

How to install Error Handling taste

How to use

Paste the text at the start of a chat or into project instructions

Manually: put the files in place

.claude/commands/prompts.csv.md

From the same set77

The whole set →

Nearby in Backend and APIs

Everything for Backend and APIs →

Questions about Error Handling taste

How do I install Error Handling taste in Claude?

There is no install command: paste the prompt into the chat as a system instruction or a first message and keep working in that conversation.

What does Error Handling taste do?

It gives the assistant a set of error-handling rules for a TypeScript backend: validation at the edges, expected errors kept apart from bugs, one central HTTP mapping, structured logging.

What do I need for the prompt to work?

Just a chat. The rules mention Zod and RFC 9457 problem+json, but those are targets for your code, not dependencies of the prompt itself.

Source text

prompts.csv · CC0-1.0

# Error handling taste of a TypeScript backend engineer
- Fail fast at the edges: validate every external input with a schema library such as Zod before it reaches business logic. Confidence: 0.90
- Separate expected domain errors (not found, conflict, validation) from unexpected bugs, and handle them differently. Confidence: 0.90
- Model expected failures as return values or a Result type; reserve throw for truly exceptional cases. Confidence: 0.70
- Define a small set of typed error classes with a stable machine-readable code field. Confidence: 0.85
- Never swallow an error silently; an empty catch block needs a comment explaining why. Confidence: 0.95
- When rethrowing, wrap the original with the cause option so the stack chain survives. Confidence: 0.85
- Only catch an error where you can add context, recover, or translate it; let everything else bubble up. Confidence: 0.85
- Map errors to HTTP responses in one central error handler, not inside each route. Confidence: 0.90
- Return RFC 9457 problem+json bodies with a code, a human message, and a request id. Confidence: 0.75
- Never leak stack traces, SQL, or internal hostnames to API clients. Confidence: 0.95
- Log each error once, at the boundary that handles it, not at every layer it passes through. Confidence: 0.85
- Include structured context in error logs (request id, user id, operation), never secrets or tokens. Confidence: 0.90
- Retry only idempotent operations, with exponential backoff, jitter, and a hard attempt limit. Confidence: 0.90
- Put a timeout on every network call; a missing timeout is a bug. Confidence: 0.95
- Use AbortController to cancel downstream work when the caller goes away. Confidence: 0.75
- Wrap flaky dependencies in a circuit breaker so one slow service cannot take the whole app down. Confidence: 0.70
- Treat unhandled promise rejections as fatal: log them and let the process restart. Confidence: 0.85
- Let a supervisor restart a crashed process instead of trying to keep a corrupted one alive. Confidence: 0.80
- Report unexpected errors to an error tracker with release and environment tags. Confidence: 0.85
- Write tests for failure paths, not only the happy path. Confidence: 0.85
- Write error messages that say what failed, with which input, and what the caller can do next. Confidence: 0.85
- Use the never type in exhaustive switch statements so new error codes break the build until handled. Confidence: 0.75