Go language some discussions and personal views on Go error handling style (i)

This is a creation in Article, where the information may have evolved or changed.

Original articles, reproduced please specify the Source: Server non-amateur research-sunface

Recently see Google go group inside there are a lot of discussion go error processing style of the problem, quite enlightening, now share with you, first please see 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 was 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 above code is cool, but the performance is a bit redundant, I have used the following an error mechanism as an alternative, I think my better

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 anyone ever used my style and found a flaw? Or is this a bad style? Although I think it's good.

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

Look at the above two kinds of error handling style, we should have seen part of the clue: the first is the comparison of traditional error processing, the second is the author believes that the more innovative error processing method. Let's not say the first kind of pros and cons,

The second first set all the variables to receive the error at the beginning, and then the error is handled in the same way, the redundancy is very high, and until the last return, that is, if the code is long enough, you have to read the middle of all the processing, where you only know the whole piece of code to understand Foo () How the error is handled.

Then a comment suggests a style that a person feels good about:

Value,err: = Bar ()

If err! = Nil {

Goto HandleError

}

.

.

.

.

HandleError:

return err

In this style, you do not need to know the code in the middle of Goto and label, you can directly error processing and return, so the code is simple, readable, high performance and low redundancy.

There is also a comment that suggests 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
}

This code is relatively concise, return to the place at a glance to know.

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)

}

Here's my personal opinion on the second piece of code in the question, there are 3 main points:

1. In the second piece of code, all meaningful code is interlocking, and every if and return should be recorded in the head, depending on the article: code nesting-a combination of states. All of the error handling in the first code is under the error code, and it's easy to see what code is causing an error, and after those if blocks, you don't need to worry about the previous x, Y, Z, because they're all legit. But in the second piece of code, you never know whether X, Y, Z is legal, and you have to continue validating the previous value each time.

2. Because the second code error handling and return mode (interlocking), we can not know the exact location of the error, the only thing to do is to completely give up and then helpless to say "code has a bug", that's all.

3. Each time you add a new code to the function of the second segment of the code, put it in a quick if code. Instead, in the first piece of code, it is not necessary because only error handling is handled externally in the IF

Here is just a simple point, I hope you can publish the common items used in the error handling mechanism, discussed together.