Why I Like Go’s Error Handling
Many folks who come to Go, complain about the error handling. It is different than many other languages, but I’ve come to really like it.
I remember when I first started learning Go, the error handling seemed very simplistic and old school (I’d been using Ruby, Elixir, Kotlin, etc.). But now (after a few years using Go), I’ve come to truly appreciate it! I think there could be a few improvements, but in general, I find it superior to exceptions and most other approaches (returning null; functional languages option/either — although this has some appeal as well, but isn’t often as readable to me, and is definitely less obvious IMHO).
First, to set the stage, go does not have exceptions, and the standard practice is to return an error to indicate an error. This is what typical code looks like for handling errors:
func doSomething(filename string) error {
f, err := os.Open(filename)
if err != nil {
log.Fatal(err) // or you might return it if not handling here
}
// do something with the open file
return nil // to indicate success/no error
}The crux is the if err != nil line, which you’ll see all over Go code.
The typical complaints I hear are:
- why not exceptions?
- this interrupts my code
