WeChat search [ brain into fried fish ] Follow this fried fish with liver-fried liver. This article GitHub github.com/eddycjy/blog has been included, with my series of articles, materials and open source Go books.
Hello everyone, I am fried fish.
When I was writing code crazy some time ago, a reader suddenly asked me a question, which made me interested:
I am still more interested, because it is a production environment, there is code, and the whole group of people are confused.
After soliciting the opinions of the friends, I shared them today. Everyone also thinks about the reasons and avoids this "pit" together.
Case number 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 "脑子进煎鱼了"
}
Please think about it, is the output of the program ?
GetErr
method called by the program nil
, and the external judgment is e == nil
, so the final output result 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, is the output of the program ?
The program calls the GetApp
method, which returns nil
, so the assigned value of base
is also nil
. Therefore, it is judged base == nil
the final output result of <nil>
is 060e534df3793c and true
, right?
The output is as follows:
2021/04/04 08:59:00 <nil>
2021/04/04 08:59:00 false
The answer is: <nil>
and false.
why
Why, what is going on with these two Go programs... too counter-intuitive? The reason behind this is essentially an understanding of the basic principles of interface in the Go language.
In case 1, although the GetErr
method does return nil
, the returned type is also a specific *MyErr
type. But the variable it receives is not a specific structure type, but type error
var e error
e = GetErr()
In the Go language, the error
type is essentially an interface:
type error interface {
Error() string
}
So go around and go back to the problem of interface type. Interface is not a simple value, but divided into type and value .
Therefore, the traditional knowledge that this nil is not that nil, must have both the type and value of nil, the nil judgment of the interface will be true .
In case 1, combined with code logic, the more suitable scenario is:
var e *MyErr
e = GetErr()
log.Println(e == nil)
The output result will be true.
In case two, the same result is also caused by the interface. Whether it is the error
interface or a custom interface, the principle behind it is the same, and the result is naturally the same.
to sum up
Today's article is equivalent to a transformation of "Go Interview Questions: A "Pit" and Principle Analysis of Go Interface". After all, it is a code transformation of the production environment, which is more suitable for real actual scenarios.
Subconscious intuition is sometimes not absolutely correct. We must correctly understand the knowledge points in the Go language to better realize the ideal and vision of leaving get off work early.
If you have any questions please comment and feedback exchange area, best relationship is mutual achievement , everybody thumbs is fried fish maximum power of creation, thanks for the support.
The article is continuously updated, you can search on [My brain is fried fish] to read, reply [160e534df37dea 000 ] I have prepared the first-line interview algorithm questions and information; this article GitHub github.com/eddycjy/blog has been included , Welcome Star to urge you to update.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。