I use to be someone who returned a nil value along with a nil error whenever I needed to indicate that a value was missing, like a database record. But recently, I’ve come around to the idea of returning either a result, or an error: never returning neither.

It may not be technically correct. If something doesn’t exist in a database, one can make the argument that a function implemented in a way that, when said aloud, would effectively be “well, I didn’t have any errors trying to find the thing; but I couldn’t find the thing either, so I got nothing successfully.” And I know that sentinel errors is generally frowned upon by certain Go language designers.

But I think it makes for more readable code; dare I say, more empathetic code. If much of what you write in Go is stuff like:

res, err := getThingFromDB()
if err != nil {
  return err
}

Then I think it’s safe to assume that the reader will think that res will have a value if err is nil. I know it’s generally not correct to assume that, just like it’s not correct to assume that a pointer value is never nil. But us coders are still human (at least for now), and doing the obvious thing is still better than being technically correct.