Structured Errors in Go

Summary

Structured errors in Gowritten almost 3 years agoThis post documents a catalogue of experiments on the topic of error management in medium-sized Go programs, specifically HTTP APIs, with certain end goals in mind around ergonomics, syntactic salt and making the lives of everyone involved easier. The final result is a simple approach and a new library that I've been using in production for a couple of months now. Error handling (or, more accurately, error management) has always ended up being a hot topic with Go. Most likely because of two things. Firstly, Go's early ideas about error handling – as with a lot of Go's design – chose to steer away from commonly found implementations such as exception handling and opted for a vastly simpler (at least from an implementation perspective) approach: return values. Secondly, the smallest, simplest form of an error in Go is a string of text. This leaves a lot of room for building on top of the simple concept of a string of text. type error interface { Error() string } Every Go programmer is familiar with this interface. The beauty in simplicity here is that any type that satisfies this interface is an error. This allows us to construct domain-specific types that satisfy our needs if those needs stretch beyond a simple string of text. Okay, so you know that. I did the one thing I hate in articles about some topic and described the absolute basics of said topic despite the fact that whoever is reading this already knows all of that before getting to the actual content. Structured logging (unrelated to lumberjack unions) I won't do that here, promise. You all know what structured logging is. It's basically a standard concept in most medium and larger systems. As Brandon Willett writes, Structured logs are non-negotiable. So what does this have to do with error handling? Well, first of all, let's define error handling by showing what it's not: data, err := service.GetAccount(...) if err != nil { return nil, err } This is not erro...