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 article. Reprint Please specify source: Server non-amateur research-sunface

Recently, Google go Group has a lot of discussion on the Go Error processing style, quite a revelation. Now share with you. First, take a look at 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 codes, 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 very cool, but the performance is a bit redundant. I have used the following error mechanism as an alternative. I think I'm 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 feel very 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 types of error handling styles. You should have seen some of the clues: the first is the comparison of traditional error processing, and the other is the author feel more innovative error processing method.

Let's not say the first kind of pros and cons,

Another variable that first sets all receive error at the beginning. Then the error is handled in a coherent way, with a high degree of redundancy. And not return until the end, that is to say the code is long enough. Then you have to read the whole process of the middle. Here you only have to read the entire code to know how Foo () errors are handled.

Then a comment suggests a style that a person thinks is good:

Value,err: = Bar ()

If err! = Nil {

Goto HandleError

}

.

.

.

.

HandleError:

return err

There is no need to know the code in the middle of Goto and label in this style. The ability to directly handle error processing and return, so the code is concise, readable, high performance and low redundancy.

Another comment 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 way of writing the code is more 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)

}

The following is my personal view of the second piece of code in the question, there are 3 main points:

1. In the second code, all of the meaningful code is interlocking, and each if and return should be recorded in the head, in detail to look at this article: code nesting-the combination of various states. All of the error handling in the first piece of code is below the error code, very easy to find out what code caused an error. And after those if code blocks. You don't need to worry about X, Y, Z. Because they are all legal. In the second piece of code, however, 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 reluctantly 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, there is no need, because only errors are handled in the IF. Everything else is being handled externally.

Here is just a simple point to initiate. I hope you will be able to publish the error handling mechanisms used in the usual projects and discuss them together.