Go's error handling doesn't sit right with me June 7, 2014 on Drew DeVault's blog

I’ll open up by saying that I am not a language designer, and I do like a lot of things about Go. I just recently figured out how to describe why Go’s error handling mechanics don’t sit right with me.

If you aren’t familiar with Go, here’s an example of how Go programmers might do error handling:

result, err := SomethingThatMightGoWrong()
if err != nil {
    // Handle error
}
// Proceed

Let’s extrapolate this:

func MightFail() {
    result, err := doStuffA()
    if err != nil {
        // Error handling omitted
    }
    result, err = doStuffB()
    if err != nil {
        // Error handling omitted
    }
    result, err = doStuffC()
    if err != nil {
        // Error handling omitted
    }
    result, err = doStuffD()
    if err != nil {
        // Error handling omitted
    }
}

Go has good intentions by removing exceptions. They add a lot of overhead and returning errors isn’t a bad thing in general. However, I spend a lot of my time writing assembly. Assembly can use similar mechanics, but I’m spoiled by it (I know, spoiled by assembly?) and I can see how Go could have done better. In assembly, goto (or instructions like it) are the only means you have of branching. It’s not like other languages where it’s taboo - you pretty much have to use it. Most assembly also makes it fancy and conditional. For example:

goto condition, label

This would jump to label given that condition is met. Like Go, assembly generally doesn’t have exceptions or anything similar. In my own personal flavor of assembly, I have my functions return error codes as well. Here’s how it’s different, though. Let’s look at some code:

call somethingThatMightFail
jp nz, errorHandler
call somethingThatMightFailB
jp nz, errorHandler
call somethingThatMightFailC
jp nz, errorHandler
call somethingThatMightFailD
jp nz, errorHandler

The difference here is that all functions return errors in the same way - by resetting the Z flag. If that flag is set, we do a quick branch (the jp instruction is short for jump) to the error handler. It’s not clear from looking at this snippet, but the error code is stored in the A register, which the errorHandler recognizes as an error code and shows an appropriate message for. We can have one error handler for an entire procedure, and it feels natural.

In Go, you have to put an if statement here. Each error caught costs you three lines of code in the middle of your important logic flow. With languages that throw exceptions, you have all the logic in a readable procedure, and some error handling at the end of it all. With Go, you have to throw a bunch of 3-line-minimum error handlers all over the middle of your procedure.

In my examples, you can still return errors like this, but you can do so with a lot less visual clutter. One line of error handling is better than 3 lines, if you ask me. Also, no one gives a damn how you format assembly code, so if you wanted to do something like this you’d be fine:

call somethingThatMightFail
  jp nz, errorHandler
call somethingThatMightFailB
  jp nz, errorHandler
call somethingThatMightFailC
  jp nz, errorHandler
call somethingThatMightFailD
  jp nz, errorHandler

Or something like this:

call somethingThatMightFail  \ jp nz, errorHandler
call somethingThatMightFailB \ jp nz, errorHandler
call somethingThatMightFailC \ jp nz, errorHandler
call somethingThatMightFailD \ jp nz, errorHandler

The point is, I think Go’s error handling stuff make your code harder to read and more tedious to write. The basic idea - return errors instead of throwing them - has good intentions. It’s just that how they’ve done it isn’t so great.

Have a comment on one of my posts? Start a discussion in my public inbox by sending an email to ~sircmpwn/public-inbox@lists.sr.ht [mailing list etiquette]

Articles from blogs I read Generated by openring

Announcing the 2020 Go Developer Survey

Help shape the future of Go Since 2016, thousands of Gophers around the world have helped the Go project by sharing their thoughts via our annual Go Developer Survey. Your feedback has played an enormous role in driving changes to our langu…

via The Go Programming Language Blog October 20, 2020

Status update, October 2020

Hi all, it’s been a while! I’ve been taking some time off this month: I’ve been hiking in Corsica (an island in the south of France) for 2 weeks! The path (called GR20) was very difficult but the gorgeous landscapes made it entirely worth it. :) I’ve uploaded…

via emersion October 16, 2020

What's cooking on Sourcehut? October 2020

Once again we meet to discuss the status of the ongoing SourceHut alpha, which has made progress by leaps and bounds this month. We’re joined by 521 new users this month, bringing our total up to 17,715. As always, please welcome them warmly and show our new…

via Blogs on Sourcehut October 15, 2020