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

Status update, May 2022

Hi all! This month’s status update will be shorter than usual, because I’ve taken some time off to visit Napoli. Discovering the city and the surrounding region was great! Of course the main reason to visit is to taste true Neapolitan pizza. I must admit, th…

via emersion May 24, 2022

What's cooking on SourceHut? May 2022

Hello everyone! We’re back at it for another month of news in the SourceHut sphere. Of our now 29,036 users, 630 are new this month: please offer them a warm welcome, and your patience, as they learn about the new platform. todo.sr.ht Comprehensive GraphQL-na…

via Blogs on Sourcehut May 16, 2022

Summary of changes for April

Hey everyone! This is the list of all the changes we've done to our projects and apps during the month of April. We'll also be reporting in our on position in the world, and on our future plans. Summary Of Changes Bicycle, released an Uxntal pla…

via Hundred Rabbits May 1, 2022