I started out thinking this was a little tedious and even came up with a little library [1] to use the panic-recover style handling within a package [2]. Howev

I started out thinking this was a little tedious and even came up with a little library [1] to use the panic-recover style handling within a package [2]. However, after a few months of writing code using that model, I find that I don't really like it and prefer the if err != nil model much more. While this can appear to be a little tedious, I've found it extremely useful once I started checking code coverage in my tests. It makes it very clear which exceptional cases you aren't testing. This in turn makes it obvious how well tested the code is. I know from looking at my code coverage what kind failures I'm handling properly and which ones I'm delegating to the caller. This allows for better documentation where API users know what failure modes to expect. [1] https://godoc.org/github.com/surullabs/fault https://godoc.org/github.com/surullabs/fault [2] https://golang.org/doc/effective_go.html#recover https://golang.org/doc/effective_go.html#recover