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.

Articles from blogs I read Generated by openring

Go Developer Survey 2023 Q1 Results

An analysis of the results from the 2023 Q1 Go Developer Survey.

via The Go Blog May 11, 2023

Summary of changes for April 2023

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 100r.co, added charging electro…

via Hundred Rabbits May 1, 2023

HDR hackfest wrap-up

Last week I’ve been attending the HDR hackfest organized by Red Hat. The trip to Prague was rather chaotic: the morning right after the SourceHut DoS incident, I got a notification that my plane was cancelled, so had to re-book a new flight and hotel. Then a…

via emersion May 1, 2023