Error Path First
Writes what happens when it fails before writing what happens when it works.
When to reach for it
Before writing code that touches something you do not control — a network call, a file, a parse, another team's service — where the failure lands on a real person's afternoon.
What changes
- The agent lists the ways the operation can fail before implementing it, including timeouts, partial success and a response that parses to nonsense.
- Each failure gets a decided behavior — retry, fall back, surface, refuse — chosen and written down before the happy path exists.
- The message the user sees is written first, in plain language, and tells them what happened and what to do next.
- No empty catch blocks and nothing logged then swallowed: anything caught is either handled or rethrown with context added.
- Each failure path is triggered at least once, so you learn the retry loop never stops before your users do.
Pairs with
- Borrow the ShapeStarts new code from the closest existing file in your repo instead of from a blank page.
- Copy the NeighboursMakes new code look like the code already around it, instead of like whatever the agent prefers.
- Keep the Diff SmallBounds a change to what you can actually read before approving it.
Error Path First
Write the failure handling before the success case. Whatever gets built second gets built worse, and failure is the path that reaches someone on their worst day.
1. List the ways this fails
For the operation you are about to write, name the failures concretely:
- It never answers, or answers too slowly to wait for.
- It answers with an error you must tell apart from the others: not found, not allowed, rate limited, server broken.
- It answers with success and a body you cannot make sense of.
- It half succeeds: three of five records written.
- It succeeds after you already gave up and sent it again.
- The input was wrong before the call was ever made.
2. Decide the behavior for each
Exactly one of four answers per failure, chosen on purpose:
- Retry — say how many times, with what backoff, and which failures are safe to retry at all. Never blindly retry something that writes.
- Fall back — say to what, and how the person can tell it happened.
- Surface — show it and stop.
- Refuse — validate earlier so the call never happens.
3. Write the user-facing message now
Plain language, no error code as the headline, and a next action. "We could not reach the payment service. Nothing was charged. Try again in a minute." Writing it now is what stops it being an afterthought later.
4. Then write the success case
It will be shorter than you expected, because the branches already exist and it only has to fill in the middle.
5. Trigger every failure once
Force them: cut the network, point at a wrong address, return broken data, make it fail on the third of five records. Confirm each does what you decided, and confirm the retry actually stops.
Rules
- Do not catch an error you have no plan for. Let it travel to something that does.
- Do not log and swallow. A caught error that only reaches a console is a bug that reaches nobody.
- Do not show raw exception text to people, and do not hide it from the logs. Two audiences, both served, differently.
- Do not retry in two places for one failure without saying so. Three retries inside three retries is nine requests at the worst moment.