(Go language) Some Discussions and opinions on the go error processing Style

Original article, reprinted with the source: Server non-amateur research-sunface

Recently, I have read many questions about the handling style of go errors in Google go group. I am very inspired to share them with you. First of all, please read a question:

Hi folks,

When I look at a lot of go code, I see the following pattern: // When I read a lot of go code, I found the following pattern:

X, err: = foo () if err! = Nil {

Return err

}
Y, err: = bar (x) if err! = Nil {

Return err

}
Z, err: = baz (y) if err! = Nil {

Return err

}
// Do something w/z
Return nil

This is cool, but comes off as a bit verbose. I 've been using the following as a replacement, which I think is a bit nicer: // the code above is cool, but the performance is somewhat redundant, I have used the following error mechanism as an alternative, and I think it is better for me.

Var (

X, y, z T

Err error

)
X, err = foo ()
If err = nil {

Y, err = bar (x)

}
If err = nil {

Z, err = baz (y)

}

If err = nil {

// Do something w/z

}

Return err

// Out of curiosity, has someone used my style and found any shortcomings? Or is this style not good? Although I think it is good

Just curious, has anyone else used this sort of thing and found a pitfall? Or perhaps has an opinion as to why it isn' t actually nice? I think it's nice =].

After reading the above two error handling styles, we should have seen some clues: the first is the traditional error processing method, and the second is the innovative error processing method that the author thinks. Not to mention the advantages and disadvantages of the first one,

The second method first sets all the variables that receive the error at the beginning, and the subsequent error processing method is interlocking. The redundancy is very high and the return is not performed until the end. That is to say, if the code is long enough, then you have to read all the processing procedures in the middle. Here, you only need to read the entire code segment to know how to handle the errors produced by foo.

Then a comment puts forward a style that I personally think is good:

Value, err: = bar ()

If err! = Nil {

Goto handleError

}

.

.

.

.

HandleError:

Return err

In this style, you do not need to know the code between goto and label. You can directly handle errors and return them. Therefore, the code is concise, readable, high-performance, and redundant.

Another comment puts forward a very special style:

If x, err: = foo (); err! = Nil {
Return err
} Else if y, err: = bar (x); err! = Nil {
Return err
} Else if z, err: = baz (y); err! = Nil {
Return err
} Else {
// Do something w/x, y, z

Return nil
}

The code in this way is concise, and the return can be seen at a glance.

The following style can save a lot of if Statements

Func checkErr (err error ){

If err! = Nil {

// Deal error here

}

}

Func main (){

Ting, err: = whatever ()

CheckErr (err)

}

My personal opinion on the second part of the code in the question is as follows:

1. in the second code, all meaningful code is interlocking, and every if and return should be recorded in the head. For details, see this article: Code nesting-combinations of various States. All error handling in the first code is under the error code, it is easy to find out what code causes an error, and after those if code blocks, you don't need to worry about the previous x, y, and z because they are all legal. However, in the second code, you never know whether x, y, and z are valid. You have to continue to verify the preceding values each time.

2. because the error handling and return methods of the second code are interlocking, we cannot know the specific location of the error, the only thing you can do is give up and say "the Code has a BUG", that's all.

3. Every time you add new code to the second code function, you should put it in an if code fast. On the contrary, this is not required in the first code, because only errors are processed in if, and others are processed externally.

This is just a simple example. I hope you can share the error handling mechanism used in common projects and discuss it together.