https://theflyingcoders.dev/tags/error-handling/Recent content in Error Handling on theflyingcodersHugoen-gbTue, 13 Oct 2026 09:00:00 +0100https://theflyingcoders.dev/blog/rest-error-taxonomy/Tue, 13 Oct 2026 09:00:00 +0100https://theflyingcoders.dev/blog/rest-error-taxonomy/<p>If your API can return an error in fifty different JSON shapes, your clients handle none of them and everyone ends up parsing a <code>message</code> string with a regex. So pick a small fixed set of shapes, give every error a stable code, and never let an endpoint invent its own. This is the taxonomy I put on every API, and it is the other half of the <a href="https://theflyingcoders.dev/blog/behaviour-driven-error-handling-lathos/">lathos post from last time</a>.</p>https://theflyingcoders.dev/blog/behaviour-driven-error-handling-lathos/Tue, 29 Sep 2026 09:00:00 +0100https://theflyingcoders.dev/blog/behaviour-driven-error-handling-lathos/<p>An error is a not-found because it says it is, not because of what type it happens to be. That one idea is what lets me delete the pile of <code>errors.Is</code> blocks out of every handler and put the whole HTTP-status decision in a single place. Here is how it hangs together, with the library I use for it, <a href="https://github.com/theflyingcodr/lathos" target="_blank" rel="noopener noreferrer">lathos</a>.</p>