An API That Accumulated Its Error Handling

One endpoint returns a JSON object naming the problem. Another returns a bare 500 with a stack trace leaked into the body. A third returns 200 with an error message buried inside a successful-looking response. None of this was decided — it's what happens when error handling isn't designed, only added, endpoint by endpoint, as each one broke in production.

Consistency here means three things hold everywhere: a real exception type for each kind of failure, one place that decides how each exception becomes a response, and one shape for the response body — whichever endpoint triggered it.

The rest of this topic builds exactly that, one piece at a time: the custom exception, the handler, centralizing the handler, and the body shape itself.