Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to solve the Go problem when writing code". In the daily operation, I believe many people have doubts about how to solve the Go problem when writing code. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubt of "how to solve the Go problem when writing code". Next, please follow the editor to study!

Case one

The code example is as follows:

Type MyErr struct {Msg string} func main () {var e error e = GetErr () log.Println (e = = nil)} func GetErr () * MyErr {return nil} func (m * MyErr) Error () string {return "brain fried fish"}

Please think about it, what is the output of this program?

The GetErr method called by the program returns nil, while the external judgment is e = = nil, so the final output is true, right?

The output is as follows:

2021-04-04 08:39:04 false

The answer is false.

Case two

The code example is as follows:

Type Base interface {do ()} type App struct {} func main () {var base Base base = GetApp () log.Println (base) log.Println (base = = nil)} func GetApp () * App {return nil} func (a * App) do () {}

Please think about it, what is the output of this program?

The program calls the GetApp method, which returns nil, so the base assigned to it is also nil. So the final output of base = = nil is determined to be and true, right?

The output is as follows:

2021-04-04 08:59:00 2021-04-04 08:59:00 false

The answer is: and false.

Why

Why, what's going on with these two Go programs? Is that too counterintuitive? The reason behind this is essentially the understanding of the basic principles of interface in the Go language.

In case 1, although the GetErr method does return nil, the return type is also a specific * MyErr type. But the variable it receives is not a specific structure type, but an error type:

Var e error e = GetErr ()

In the Go language, the error type is essentially interface:

Type error interface {Error () string}

So it comes back to the question of interface types. Interface is not a simple value, but is divided into types and values.

Therefore, the traditional cognition of this nil is not that nil, and the nil judgment of interface will be true only if the type and value are both nil at the same time.

In case 1, combined with the code logic, what is more consistent with the scenario is:

Var e * MyErr e = GetErr () log.Println (e = = nil)

The output will be true.

In case 2, the result is the same, and the reason is interface. Whether it is an error interface (interface) or a custom interface, the principle behind it is the same, and the result is naturally the same.

At this point, the study on "how to solve Go problems when writing code" is over. I hope to be able to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.