Avoid checking if error is nil repetition?

Question

I\'m currently learning go and some of my code looks like this:

a, err := doA()
if err != nil {
  return nil, err
}
b, err := doB(a)
if err != nil {
  return nil         


        

Answer 1

This is a common complaint, and there are several answers to it.

Here are a few common ones:

1 - It's not so bad

This is a very common reaction to these complaints. The fact you have a few extra lines of code in your code is not in fact so bad. It's just a bit of cheap typing, and very easy to handle when on the reading side.

2 - It's actually a good thing

This is based on the fact that typing and reading these extra lines is a very good reminder that in fact your logic might escape at that point, and you have to undo any resource management that you've put in place in the lines preceding it. This is usually brought up in comparison with exceptions, which can break the flow of logic in an implicit way, forcing the developer to always have the hidden error path in mind instead. Some time ago I wrote a more in-depth rant about this here.

3 - Use panic/recover

In some specific circumstances, you may avoid some of that work by using panic with a known type, and then using recover right before your package code goes out into the world, transforming it into a proper error and returning that instead. This technique is seen most commonly to unroll recursive logic such as (un)marshalers.

I personally try hard to not abuse this too much, because I correlate more closely with points 1 and 2.

4 - Reorganize the code a bit

In some circumstances, you can reorganize the logic slightly to avoid the repetition.

As a trivial example, this:

err := doA()
if err != nil {
    return err
}
err := doB()
if err != nil {
    return err
}
return nil

can also be organized as:

err := doA()
if err != nil {
    return err
}
return doB()

5 - Use named results

Some people use named results to strip out the err variable from the return statement. I'd recommend against doing that, though, because it saves very little, reduces the clarity of the code, and makes the logic prone to subtle issues when one or more results get defined before the bail-out return statement.

6 - Use the statement before the if condition

As Tom Wilde well reminded in the comment below, if statements in Go accept a simple statement before the condition. So you can do this:

if err := doA(); err != nil {
    return err
}

This is a fine Go idiom, and used often.

In some specific cases, I prefer to avoid embedding the statement in this fashion just to make it stand on its own for clarity purposes, but this is a subtle and personal thing.