# Handle errors by class, not by exhaustive list

The error reference states it plainly: values in error objects may expand, and type values can grow over time. New SSE event types can also appear. Your handling must tolerate the unknown.

## What to do

1. Branch on the HTTP status class first: 4xx means fix the request or the account, 429 means back off, 5xx means retry with backoff. Then refine by known error types (enforced_spend_limit_reached, overloaded_error) for the special cases.
2. Give every switch a default branch. Unknown error type with a 429 status: honor retry-after and back off. Unknown type with a 500: exponential backoff. Unknown type with a 400: log it loudly and alert, because something new is wrong with the request.
3. In SSE consumers, log and continue on unknown event types. Never crash the stream parser on an event you have not seen before.
4. Pin the anthropic-version header your integration was built against, and read the changelog before bumping it. Behavior changes ride the version header.

## The trap

An exhaustive match with no default that throws on the unknown. It works until the day Anthropic ships a new error type, and then every request that hits it becomes a crash instead of a handled error. The other trap: bumping the API version header casually and discovering behavior changed under a passing test suite.

## Checklist

- Every error-type switch in your codebase ends with a default. Grep for switches without one.
- Treat "unknown error type" as a signal to read the changelog, not as a bug in your code.