原文鏈接： 聽說，99% 的 Go 程式員都被 defer 坑過
先宣告：我被坑過，
之前寫 Go 專欄時，寫過一篇文章：Go 專欄｜錯誤處理：defer，panic 和 recover，有小伙伴留言說：道理都懂，但還是不知道怎么用，而且還總出現莫名奇妙的問題，
出問題就對了，這個小東西壞的很，一不留神就出錯，
所以，面對這種情況，我們今天就不講道理了，直接把我珍藏多年的代碼一把梭，憑借多年踩坑經歷和寫 BUG 經驗，我要站著把這個坑邁過去，
一、
先來一個簡單的例子熱熱身：
package main
import (
"fmt"
)
func main() {
defer func() {
fmt.Println("first")
}()
defer func() {
fmt.Println("second")
}()
fmt.Println("done")
}
輸出：
done
second
first
這個比較簡單，defer 陳述句的執行順序是按呼叫 defer 陳述句的倒序執行，
二、
看看這段代碼有什么問題？
for _, filename := range filenames {
f, err := os.Open(filename)
if err != nil {
return err
}
defer f.Close()
}
這段代碼其實很危險，很可能會用盡所有檔案描述符，因為 defer 陳述句不到函式的最后一刻是不會執行的，也就是說檔案始終得不到關閉，所以切記，一定不要在 for 回圈中使用 defer 陳述句，
那怎么優化呢？可以將回圈體單獨寫一個函式，這樣每次回圈的時候都會呼叫關閉函式，
如下：
for _, filename := range filenames {
if err := doFile(filename); err != nil {
return err
}
}
func doFile(filename string) error {
f, err := os.Open(filename)
if err != nil {
return err
}
defer f.Close()
}
三、
看看這三個函式的輸出結果是什么？
package main
import (
"fmt"
)
func a() (r int) {
defer func() {
r++
}()
return 0
}
func b() (r int) {
t := 5
defer func() {
t = t + 5
}()
return t
}
func c() (r int) {
defer func(r int) {
r = r + 5
}(r)
return 1
}
func main() {
fmt.Println("a = ", a())
fmt.Println("b = ", b())
fmt.Println("c = ", c())
}
公布答案：
a = 1
b = 5
c = 1
你答對了嗎？
說實話剛開始看到這個結果時，我是相當費解，完全不知道怎么回事，
但可以看到，這三個函式都有一個共同特點，它們都有一個命名回傳值，并且都在函式中參考了這個回傳值，
參考的方式分兩種：分別是閉包和函式引數，
先看 a() 函式：
閉包通過 r++ 修改了外部變數，回傳值變成了 1，
相當于：
func aa() (r int) {
r = 0
// 在 return 之前，執行 defer 函式
func() {
r++
}()
return
}
再看 b() 函式：
閉包內修改的只是區域變數 t，而外部變數 t 不受影響，所以還是回傳 5，
相當于：
func bb() (r int) {
t := 5
// 賦值
r = t
// 在 return 之前，執行 defer 函式
// defer 函式沒有對回傳值 r 進行修改，只是修改了變數 t
func() {
t = t + 5
}()
return
}
最后是 c 函式：
引數傳遞是值拷貝，實參不受影響，所以還是回傳 1，
相當于：
func cc() (r int) {
// 賦值
r = 1
// 這里修改的 r 是函式形參的值
// 值拷貝，不影響實參值
func(r int) {
r = r + 5
}(r)
return
}
那么，為了避免寫出這么令人意外的代碼，最好在定義函式時就不要使用命名回傳值，或者如果使用了，就不要在 defer 中參考，
再看下面兩個例子：
func d() int {
r := 0
defer func() {
r++
}()
return r
}
func e() int {
r := 0
defer func(i int) {
i++
}(r)
return 0
}
d = 0
e = 0
回傳值符合預期，再也不用絞盡腦汁猜了，
四、
defer 運算式的函式如果在 panic 后面，則這個函式無法被執行，
func main() {
panic("a")
defer func() {
fmt.Println("b")
}()
}
輸出如下，b 沒有列印出來，
panic: a
goroutine 1 [running]:
main.main()
xxx.go:87 +0x4ce
exit status 2
而如果 defer 在前，則可以執行，
func main() {
defer func() {
fmt.Println("b")
}()
panic("a")
}
輸出：
b
panic: a
goroutine 1 [running]:
main.main()
xxx.go:90 +0x4e7
exit status 2
五、
看看下面這段代碼的執行順序：
func G() {
defer func() {
fmt.Println("c")
}()
F()
fmt.Println("繼續執行")
}
func F() {
defer func() {
if err := recover(); err != nil {
fmt.Println("捕獲例外:", err)
}
fmt.Println("b")
}()
panic("a")
}
func main() {
G()
}
順序如下：
- 呼叫
G()函式； - 呼叫
F()函式； F()中遇到panic，立刻終止，不執行panic之后的代碼；- 執行
F()中defer函式，遇到recover捕獲錯誤，繼續執行defer中代碼，然后回傳； - 執行
G()函式后續代碼，最后執行G()中defer函式，
輸出：
捕獲例外: a
b
繼續執行
c
五、
看看下面這段代碼的執行順序：
func G() {
defer func() {
if err := recover(); err != nil {
fmt.Println("捕獲例外:", err)
}
fmt.Println("c")
}()
F()
fmt.Println("繼續執行")
}
func F() {
defer func() {
fmt.Println("b")
}()
panic("a")
}
func main() {
G()
}
順序如下：
- 呼叫
G()函式； - 呼叫
F()函式； F()中遇到panic，立刻終止，不執行panic之后的代碼；- 執行
F()中defer函式，由于沒有recover，則將panic拋到G()中； G()收到panic則不會執行后續代碼，直接執行defer函式；defer中捕獲F()拋出的例外a，然后繼續執行，最后退出，
輸出：
b
捕獲例外: a
c
六、
看看下面這段代碼的執行順序：
func G() {
defer func() {
fmt.Println("c")
}()
F()
fmt.Println("繼續執行")
}
func F() {
defer func() {
fmt.Println("b")
}()
panic("a")
}
func main() {
G()
}
順序如下：
- 呼叫
G()函式； - 呼叫
F()函式； F()中遇到panic，立刻終止，不執行panic之后的代碼；- 執行
F()中defer函式，由于沒有recover，則將panic拋到G()中； G()收到panic則不會執行后續代碼，直接執行defer函式；- 由于沒有
recover，直接拋出F()拋過來的例外a，然后退出，
輸出：
b
c
panic: a
goroutine 1 [running]:
main.F()
xxx.go:90 +0x5b
main.G()
xxx.go:82 +0x48
main.main()
xxx.go:107 +0x4a5
exit status 2
七、
看看下面這段代碼的執行順序：
func G() {
defer func() {
// goroutine 外進行 recover
if err := recover(); err != nil {
fmt.Println("捕獲例外:", err)
}
fmt.Println("c")
}()
// 創建 goroutine 呼叫 F 函式
go F()
time.Sleep(time.Second)
}
func F() {
defer func() {
fmt.Println("b")
}()
// goroutine 內部拋出panic
panic("a")
}
func main() {
G()
}
順序如下：
- 呼叫
G()函式； - 通過 goroutine 呼叫
F()函式； F()中遇到panic，立刻終止，不執行panic之后的代碼；- 執行
F()中defer函式，由于沒有recover，則將panic拋到G()中； - 由于 goroutine 內部沒有進行
recover，則 goroutine 外部函式，也就是G()函式是沒辦法捕獲的，程式直接崩潰退出，
輸出：
b
panic: a
goroutine 6 [running]:
main.F()
xxx.go:96 +0x5b
created by main.G
xxx.go:87 +0x57
exit status 2
八、
最后再說一個 recover 的回傳值問題：
defer func() {
if err := recover(); err != nil {
fmt.Println("捕獲例外:", err.Error())
}
}()
panic("a")
recover 回傳的是 interface {} 型別，而不是 error 型別，所以這樣使用的話會報錯：
err.Error undefined (type interface {} is interface with no methods)
可以這樣來轉換一下：
defer func() {
if err := recover(); err != nil {
fmt.Println("捕獲例外:", fmt.Errorf("%v", err).Error())
}
}()
panic("a")
或者直接列印結果：
defer func() {
if err := recover(); err != nil {
fmt.Println("捕獲例外:", err)
}
}()
panic("a")
輸出：
捕獲例外: a
以上就是本文的全部內容，其實寫過其他的語言的同學都知道，關閉檔案句柄，釋放鎖等操作是很容易忘的，而 Go 語言通過 defer 很好地解決了這個問題，但在使用程序中還是要小心，
本文總結了一些容踩坑的點，希望能夠幫助大家少寫 BUG，如果大家覺得有用的話，歡迎點贊和轉發，
文章中的腦圖和原始碼都上傳到了 GitHub，有需要的同學可自行下載，
原始碼地址：
- https://github.com/yongxinz/gopher/tree/main/sc
推薦閱讀：
- gRPC，爆贊
- 使用 grpcurl 通過命令列訪問 gRPC 服務
- 推薦三個實用的 Go 開發工具
- 被 Docker 日志坑慘了
參考：
- 《Go 語言核心編程》
- https://www.jianshu.com/p/63e3d57f285f
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/322948.html
標籤：Go