共计 2882 个字符,预计需要花费 8 分钟才能阅读完成。
在日常工作中,咱们常常应用 err != nil
来判断程序或函数是否报错,或者应用 defer {recover = err}
来判断是否有 panic
严重错误,但稍不留神,很容易掉进 err shadow
的陷阱。
1. 变量作用域
package main | |
import "fmt" | |
func main() { | |
x := 100 | |
func() { | |
x := 200 // x will shadow outer x | |
fmt.Println(x) | |
}() | |
fmt.Println(x) | |
} |
输入如下:
200 | |
100 |
后果剖析:x
变量在 func
外面打印为 200
,在外层打印为 100
,这就是变量的作用域 (variable scope
)。func
外面的变量 x
是一个新变量,只不过与外层 x
重名了 (variable redeclaration
),此时里层 x
的作用域仅限于 func {} block
,而外层 x
的作用域则是 main {} block
,此时里层变量 x
产生了 variable shadowing
,外层 x
不受影响,仍然是 100
。
改一下写法:
package main | |
import "fmt" | |
func main() { | |
x := 100 | |
func() { | |
x = 200 // x will override outer x | |
fmt.Println(x) | |
}() | |
fmt.Println(x) | |
} |
输入如下:
200 | |
200 |
此时,func
外面的变量 x
仅仅是笼罩了外层 x
,并没有定义新的变量,所以内外层输入都是 200
。
2. err shadow – 无名 error
package main | |
import ( | |
"fmt" | |
"os" | |
) | |
func main() {fmt.Println("func err1:", test1()) | |
} | |
func test1() error { | |
var err error | |
defer func() {fmt.Println("defer err1:", err) | |
}() | |
if _, err := os.Open("xxx"); err != nil {return err} | |
return nil | |
} |
输入如下:
defer err1: <nil> | |
func err1: open xxx: no such file or directory |
后果剖析:func test1
首先定义了 var err error
变量,但上面的 os.Open
报错应用 err :=
被部分 err shadow
了,尽管显式应用了 return err
返回谬误,但因为 test1() error
返回参数是无名的 (unnamed variable
),导致 defer
中 err
获取不到被 err shadow
的谬误 err
,取的依然是外层初始化 var err error
值,所以输入为 err1: <nil>
。
只须要将第 19
行改一下,即可防止 err shadow
:
if _, err = os.Open("xxx"); err != nil {return err}
输入如下:
defer err1: open xxx: no such file or directory | |
func err1: open xxx: no such file or directory |
3. err shadow – 有名 error
package main | |
import ( | |
"fmt" | |
"os" | |
) | |
func main() {fmt.Println("func err2:", test2()) | |
} | |
func test2() (err error) {defer func() {fmt.Println("defer err2:", err) | |
}() | |
if _, err := os.Open("xxx"); err != nil {return // return without err will compilation error} | |
return | |
} |
下面的 test2
运行会有编译报错,这是 go compiler
在编译时做了 variable shadowing
查看,发现有就间接编译报错。批改一下即可:
func main() {fmt.Println("func err3:", test3()) | |
} | |
func test3() (err error) {defer func() {fmt.Println("defer err3:", err) | |
}() | |
if _, err := os.Open("xxx"); err != nil {return err} | |
return | |
} |
输入如下:
defer err3: open xxx: no such file or directory | |
func err3: open xxx: no such file or directory |
4. 嵌套 err shadow
package main | |
import ( | |
"encoding/json" | |
"fmt" | |
"os" | |
) | |
func main() {fmt.Println("func err4:", test4()) | |
} | |
func test4() (err error) {defer func() {fmt.Println("defer err4:", err) | |
}() | |
if _, err := os.Open("xxx"); err == nil {if err := json.Unmarshal([]byte("{}"), &struct{}{}); err == nil {fmt.Println("OK") | |
} | |
} | |
return | |
} |
输入如下:
defer err4: <nil> | |
func err4: <nil> |
后果剖析:func test4()
是一个有名返回 err error
,则函数初始化时会 var err error
定义对应的有名变量 (named variable
),但上面的 os.Open
或 json.Unmarshal
都应用了 err :=
重定义 err
变量,造成了 err shadow
,因而在函数退出时,外层 err
仍然是 nil
,defer
获取也就是 nil
。
改一下写法即可:
func main() {fmt.Println("func err5:", test5()) | |
} | |
func test5() (err error) {defer func() {fmt.Println("defer err5:", err) | |
}() | |
if _, err = os.Open("xxx"); err == nil {if err = json.Unmarshal([]byte("{}"), &struct{}{}); err == nil {fmt.Println("OK") | |
} | |
} | |
return | |
} |
输入如下:
defer err5: open xxx: no such file or directory | |
func err5: open xxx: no such file or directory |
5. 小结
本文通过几个实例,剖析了在理论工作中很容易呈现的 err shadow
问题,究其实质起因次要是变量作用域引起的,在官网文档中提到:An identifier declared in a block may be redeclared in an inner block. While the identifier of the inner declaration is in scope, it denotes the entity declared by the inner declaration
.
另外,在函数返回值命名方面,咱们须要思考无名、有名参数的状况,在保障代码逻辑正确的状况下,倡议应用工具 go linter
或 go vet
来检测编译器没检测到的 variable shadowing
,防止踩到坑。