Error Handling Beyond the Happy Path

Ask a model to build a checkout flow and you will get a beautiful checkout flow — for the customer whose card works, whose network holds, whose session is valid, and whose browser does not reload mid-request. Ask what happens to the other customer and you find a try/catch that logs to the console and returns null.

This is the defining shape of AI-generated code. Not that it is wrong, but that it is complete in one dimension and hollow in the other. The happy path is often better than what a rushed human would write. The failure paths are decoration.

The gap matters because failures in production are not exotic. Payment providers time out. Storage buckets return 403 when a policy changes. A user double-clicks Submit. Someone's corporate proxy strips a header. Your job is not to prevent these — it is to make sure each one has a defined outcome instead of a shrug.

The five patterns to hunt for

Search your codebase for these specifically. In an app of any size you will find all five.

The empty catch. A catch block that logs and continues, so the function returns as though it succeeded. The caller sees success. The user sees a spinner that stops. Nothing anywhere records that the operation did not happen.

The optimistic UI that never reconciles. The interface shows the item as saved the instant you click, and if the request fails, the state is never rolled back. The user believes their work is stored. It is not. They find out on their next login, and they are furious, correctly.

The unchecked response. Fetch resolves, the code goes straight to reading the JSON body, and nobody checks the status code. A 500 with an HTML error page becomes a parse error three functions away from the actual problem, and you spend an hour debugging the wrong file.

Retry on things that must not be retried. A blanket retry wrapper around every network call is common in generated code and genuinely dangerous when the call charges a card or sends an email. Twice.

The generic error screen. Every failure, from an expired session to a validation problem the user could fix in two seconds, renders "Something went wrong. Please try again." The user tries again. It goes wrong again.

A taxonomy that makes the decision for you

Most error handling arguments are actually classification failures. Sort every failure into one of four buckets and the correct behavior falls out.

The bucket most codebases skip entirely is the fourth. An app where the recommendations service being down takes the whole product page with it is an app whose availability is the product of every dependency's availability. Decide, per dependency, whether it is load-bearing or optional — and if it is optional, make the failure path show a smaller page rather than no page.

Retries: the rules that keep you out of trouble

Retry only idempotent operations, or operations you have made idempotent with a key. A GET is safe. A POST that creates a charge is not, unless you send an idempotency key so the provider recognizes the duplicate and returns the original result instead of charging again. Stripe, and most serious payment APIs, support this precisely because retrying is otherwise unsafe — a subtlety that surfaces the hard way when test mode works and live mode fails.

Use exponential backoff with jitter, cap at three attempts, and add a circuit breaker for anything you call frequently. Without backoff, a dependency that gets slow receives more traffic exactly when it can least handle it, and your retries become the outage. Uncapped retry loops are also a favorite way to discover an app making infinite API calls against a metered provider.

And set timeouts on everything. An HTTP client with no timeout will wait indefinitely, which converts a slow dependency into exhausted connections and a hung app. This is a one-line fix that generated code almost never includes.

Make failures visible to you and recoverable for the user

Two audiences, two different jobs.

For you: every handled error should still be recorded somewhere queryable, with enough context to act — user id, request id, inputs (redacted), and the release version. An error that is caught and forgotten is worse than an uncaught one, because the uncaught one at least produced a stack trace. If nothing is currently collecting these, that is the first hour of work in adding observability to an app you inherited.

For the user: give them somewhere to go. A useful failure state names what happened in their terms, says whether their data was saved, and offers the next action — retry, edit the input, or contact support with a reference id. The reference id is a small touch that pays for itself the first time a support conversation starts with a code you can paste directly into your error tracker instead of "sometime yesterday afternoon."

Then add the boundaries. On the front end, a render error in one widget should not blank the entire application — an uncaught exception in a React tree unmounts everything above it, which is precisely the mechanism behind a blank white screen in production. Wrap major sections so a failure is contained to the panel it happened in.

Where errors hide: the async and background paths

The failures you will discover last are the ones nobody is watching. A promise without a catch. A background job that throws after the HTTP response was already sent. A queue consumer that fails and moves on with no dead letter queue, so the work is simply gone.

Register global handlers for unhandled rejections and uncaught exceptions and route them to your error tracker. Give every queue a dead letter destination and, more importantly, someone who looks at it. And make failures in fire-and-forget work loud, because the whole point of fire-and-forget is that no user is waiting to notice — the reason emails silently not sending in production is such a persistent class of bug. If you are moving work off the request path, the failure semantics are half the design: see moving slow work into background jobs.

Frequently asked questions

Why does AI-generated code handle errors so badly? Because it optimizes for the specification it was given, and your prompt described what should happen when things work. Error handling requires knowing what your product should do when a dependency fails — whether a failed analytics call should block a purchase, whether a declined card should preserve the cart. Those are business decisions no model can infer from a feature description.

Should I retry failed API calls automatically? Only for transient failures on idempotent operations. Retrying a timeout on a read is free; retrying a payment or an email send without an idempotency key charges twice or sends twice. Use exponential backoff with jitter, cap the attempts, and never retry a 4xx that indicates a user-correctable problem — it will fail identically every time.

What should an error message actually say? What went wrong in the user's terms, whether their data was saved, and what to do next. Include a reference id that maps to the entry in your error tracker. Never show a raw stack trace or database message to an end user — it is unhelpful to them and a genuine information disclosure risk to you.

---

If your app handles the happy path beautifully and everything else with a shrug, the failures are already happening — you just have no record of them. SprintX hardens AI-generated applications: failure classification, safe retries, error boundaries, and instrumentation that tells you what is actually breaking. Send us your repo and we will show you where the silent failures are.