Exploring Error Handling Patterns in Go

My first (real world) exposure to exceptions was Python. I was a bit above novice. I would write some code, run it, and it would die of some horrible exception. I would catch that exception, try again, and die again. Lather, rinse, repeat. Eventually I would wrap everything in try-except blocks. Talk about verbose; tab indents everywhere. You can often end up handling exceptions somewhere not immediately close to the call that failed.

I liked when I started with Go (mostly due to concurrency primatives, but errors were nice too). In my day job, many of the errors have a need for custom handling and I get that for "free" in Go and I am never surprised by a program crash because I failed to read the docs on a function and what exceptions it may throw (or undocumented exceptions it may throw due to one of its dependencies). I can see right in the signature that I have an error to potentially handle.

Seriously, exceptions are very different from returning an error. Confusing error return with checked exception tells it all. A checked exception is just an exception type specification.

When you read code with a call to a function returning an error, you see how the error is handled. With exception, unless there is a try/catch close surrounding the call, you don't know where and how an exception is handled.

To me, throwing exceptions is like littering the streets. That feels fine for the one who does it, because he assume someone else will take care of the mess. But the problem is taking care of it, who, how when ? With big projects, this strategy is unmanageable.

Correctly handled exceptions don't make middle-ware easier to write or more readable. On the contrary.

You know that programs are not only http handlers, right ?

The first time I used Go on a big project, error handling bugged me enough that I wrote a package that let me use errors like exceptions:

https://github.com/s4y/go-exc

I’m not sure if I’d use it again today, but it was a fun exercise.

"The flipside of easy-to-learn is there's no payoff for getting better with the language. Your code will always be exactly as tedious as novices' code because they'd rather conserve compiler cycles than spend them to amplify programmers' work."

In my years of experience with the language, this is, bluntly, untrue. Go, used properly, is slightly more verbose than most comparable code in Python or Perl. If someone is writing code that is shot through with boilerplate in Go, then I would say that they may be using "Oh, Go just needs lots of boilerplate" as an excuse.

The problem isn't that Go lacks abstraction mechanisms; the problem is that you need to learn how to use the ones that are there and not sit there pining for the ones that are not. I find this to be almost exactly like learning Haskell; you need to learn to use what is there, not sit there pining for what you don't have. Also like Haskell, there are some particular points that it all comes together at once and hurts you, but, then again, there's some places in Go where I've had big wins using the language features too. It does cut both ways. (I've done some fun things with interfaces, and the pervasive io.Reader/Writer support, while not necessarily a feature of the language, can make certain things amazingly easy to do while still retaining incredible flexibility.)

As one example I went through personally, while by the time I learned Go I had a lot of non-OO experience, so I wasn't as stuck on inheritance as someone who only did OO-languages for the last 10 years would be, I still had to adjust to using a generally-OO language (by my standard of the term) that did not support inheritance. It has now been literally plural years since I missed inheritance in Go. (In fact, quite the opposite; I miss easy composition in my other OO languages! Yes, Virginia, it is possible to miss features Go has when using other languages, despite what it may seem like if you only read the criticisms.) But my first couple of months were a bit rougher before I internalized how the composition works and affects the design of your code.

Complaining that Go code is all boilerplate is like someone who tried Haskell but complains that it's just an especially inconvenient imperative language and you end up doing everything in IO anyhow. Nope... you have not yet gotten past your "Writing X in Y" phase. That's fine; there's a ton of languages and platforms and libraries in the world. If you didn't get a short-term payoff from using it, go ahead and move on. But you haven't attained enough mastery to go around slagging on the language/platform/library yet.

(And, again, let me say that, yes, it is somewhat more verbose that Python or something. If you've shrunk your Go down to that level, you probably went too far and are doing something ill-advised. But I find that in practice, for most tasks, it is not that much more verbose. There are exceptions, like heavy duty GUI code or (IMHO) scientific code; the solution is not to use Go for those.)

The thing that bugs me is that if you ignore the error (by simply not checking for it), it's still there, possibly insidiously corrupting runtime state. Imagine trying to debug a file format corruption that happened because some obscure part of the code tried to add to the format and instead errored (silently) and added garbage and then the code just kept chugging along until the state REALLY messed things up.

The thing many programmers don't seem to realize is that a program is a model of a design in the programmer's mind. If the model goes off the rails of the expected design/behavior in any way, that should be considered very bad ASAP... or as many languages treat it, "exceptional".