Go程序員踩過的defer坑錯(cuò)誤處理
前言
先聲明：我被坑過。
之前寫 Go 專欄時(shí)，寫過一篇文章：Go 專欄｜錯(cuò)誤處理：defer，panic 和 recover。有小伙伴留言說：道理都懂，但還是不知道怎么用，而且還總出現(xiàn)莫名奇妙的問題。
出問題就對(duì)了，這個(gè)小東西壞的很，一不留神就出錯(cuò)。
所以，面對(duì)這種情況，我們今天就不講道理了。直接把我珍藏多年的代碼一把梭，憑借多年踩坑經(jīng)歷和寫 BUG 經(jīng)驗(yàn)，我要站著把這個(gè)坑邁過去。
一、簡單的例子
先來一個(gè)簡單的例子熱熱身：
package?main
import?(
????"fmt"
)
func?main()?{
????defer?func()?{
????????fmt.Println("first")
????}()
????defer?func()?{
????????fmt.Println("second")
????}()
????fmt.Println("done")
}
輸出：
done
second
first
這個(gè)比較簡單，defer 語句的執(zhí)行順序是按調(diào)用 defer 語句的倒序執(zhí)行。
二、一定不要在 for 循環(huán)中使用 defer 語句
看看這段代碼有什么問題？
for?_,?filename?:=?range?filenames?{
????f,?err?:=?os.Open(filename)
????if?err?!=?nil?{
????????return?err
????}
????defer?f.Close()
}
這段代碼其實(shí)很危險(xiǎn)，很可能會(huì)用盡所有文件描述符。因?yàn)?nbsp;defer 語句不到函數(shù)的最后一刻是不會(huì)執(zhí)行的，也就是說文件始終得不到關(guān)閉。所以切記，一定不要在 for 循環(huán)中使用 defer 語句。
那怎么優(yōu)化呢？可以將循環(huán)體單獨(dú)寫一個(gè)函數(shù)，這樣每次循環(huán)的時(shí)候都會(huì)調(diào)用關(guān)閉函數(shù)。
如下：
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()
}
三、定義函數(shù)時(shí)就不要使用命名返回值
看看這三個(gè)函數(shù)的輸出結(jié)果是什么？
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
你答對(duì)了嗎？
說實(shí)話剛開始看到這個(gè)結(jié)果時(shí)，我是相當(dāng)費(fèi)解，完全不知道怎么回事。
但可以看到，這三個(gè)函數(shù)都有一個(gè)共同特點(diǎn)，它們都有一個(gè)命名返回值，并且都在函數(shù)中引用了這個(gè)返回值。
引用的方式分兩種：分別是閉包和函數(shù)參數(shù)。
先看 a() 函數(shù)：
閉包通過 r++ 修改了外部變量，返回值變成了 1。
相當(dāng)于：
func?aa()?(r?int)?{
????r?=?0
????//?在?return?之前，執(zhí)行?defer?函數(shù)
????func()?{
????????r++
????}()
????return
}
再看 b() 函數(shù)：
閉包內(nèi)修改的只是局部變量 t，而外部變量 t 不受影響，所以還是返回 5。
相當(dāng)于：
func?bb()?(r?int)?{
????t?:=?5
????//?賦值
????r?=?t
????//?在?return?之前，執(zhí)行?defer?函數(shù)
????//?defer?函數(shù)沒有對(duì)返回值?r?進(jìn)行修改，只是修改了變量?t
????func()?{
????????t?=?t?+?5
????}()
????return
}
最后是 c 函數(shù)：
參數(shù)傳遞是值拷貝，實(shí)參不受影響，所以還是返回 1。
相當(dāng)于：
func?cc()?(r?int)?{
????//?賦值
????r?=?1
????//?這里修改的?r?是函數(shù)形參的值
????//?值拷貝，不影響實(shí)參值
????func(r?int)?{
????????r?=?r?+?5
????}(r)
????return
}
那么，為了避免寫出這么令人意外的代碼，最好在定義函數(shù)時(shí)就不要使用命名返回值?；蛘呷绻褂昧耍筒灰?nbsp;defer 中引用。
再看下面兩個(gè)例子：
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
返回值符合預(yù)期，再也不用絞盡腦汁猜了。
四、defer 表達(dá)式的函數(shù)如果在 panic 后面，則這個(gè)函數(shù)無法被執(zhí)行。
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 在前，則可以執(zhí)行。
func?main()?{
????defer?func()?{
????????fmt.Println("b")
????}()
????panic("a")
}
輸出：
b panic:?a goroutine?1?[running]: main.main() ????xxx.go:90?+0x4e7 exit?status?2
五、執(zhí)行順序
看看下面這段代碼的執(zhí)行順序：
func?G()?{
????defer?func()?{
????????fmt.Println("c")
????}()
????F()
????fmt.Println("繼續(xù)執(zhí)行")
}
func?F()?{
????defer?func()?{
????????if?err?:=?recover();?err?!=?nil?{
????????????fmt.Println("捕獲異常:",?err)
????????}
????????fmt.Println("b")
????}()
????panic("a")
}
func?main()?{
????G()
}
順序如下：
- 調(diào)用 G() 函數(shù)；
- 調(diào)用 F() 函數(shù)；
- F() 中遇到 panic，立刻終止，不執(zhí)行 panic 之后的代碼；
- 執(zhí)行 F() 中 defer 函數(shù)，遇到 recover 捕獲錯(cuò)誤，繼續(xù)執(zhí)行 defer 中代碼，然后返回；
- 執(zhí)行 G() 函數(shù)后續(xù)代碼，最后執(zhí)行 G() 中 defer 函數(shù)。
輸出：
捕獲異常: a
b
繼續(xù)執(zhí)行
c
五、捕獲異常執(zhí)行順序
看看下面這段代碼的執(zhí)行順序：
func?G()?{
????defer?func()?{
????????if?err?:=?recover();?err?!=?nil?{
????????????fmt.Println("捕獲異常:",?err)
????????}
????????fmt.Println("c")
????}()
????F()
????fmt.Println("繼續(xù)執(zhí)行")
}
func?F()?{
????defer?func()?{
????????fmt.Println("b")
????}()
????panic("a")
}
func?main()?{
????G()
}
順序如下：
- 調(diào)用 G() 函數(shù)；
- 調(diào)用 F() 函數(shù)；
- F() 中遇到 panic，立刻終止，不執(zhí)行 panic 之后的代碼；
- 執(zhí)行 F() 中 defer 函數(shù)，由于沒有 recover，則將 panic 拋到 G() 中；
- G() 收到 panic 則不會(huì)執(zhí)行后續(xù)代碼，直接執(zhí)行 defer 函數(shù)；
- defer 中捕獲 F() 拋出的異常 a，然后繼續(xù)執(zhí)行，最后退出。
輸出：
b
捕獲異常: a
c
六、函數(shù)執(zhí)行順序
看看下面這段代碼的執(zhí)行順序：
func?G()?{
????defer?func()?{
????????fmt.Println("c")
????}()
????F()
????fmt.Println("繼續(xù)執(zhí)行")
}
func?F()?{
????defer?func()?{
????????fmt.Println("b")
????}()
????panic("a")
}
func?main()?{
????G()
}
順序如下：
- 調(diào)用 G() 函數(shù)；
- 調(diào)用 F() 函數(shù)；
- F() 中遇到 panic，立刻終止，不執(zhí)行 panic 之后的代碼；
- 執(zhí)行 F() 中 defer 函數(shù)，由于沒有 recover，則將 panic 拋到 G() 中；
- G() 收到 panic 則不會(huì)執(zhí)行后續(xù)代碼，直接執(zhí)行 defer 函數(shù)；
- 由于沒有 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
七、外部函數(shù)捕獲異常執(zhí)行順序
看看下面這段代碼的執(zhí)行順序：
func?G()?{
????defer?func()?{
????????//?goroutine?外進(jìn)行?recover
????????if?err?:=?recover();?err?!=?nil?{
????????????fmt.Println("捕獲異常:",?err)
????????}
????????fmt.Println("c")
????}()
????//?創(chuàng)建?goroutine?調(diào)用?F?函數(shù)
????go?F()
????time.Sleep(time.Second)
}
func?F()?{
????defer?func()?{
????????fmt.Println("b")
????}()
????//?goroutine?內(nèi)部拋出panic
????panic("a")
}
func?main()?{
????G()
}
順序如下：
- 調(diào)用 G() 函數(shù)；
- 通過 goroutine 調(diào)用 F() 函數(shù)；
- F() 中遇到 panic，立刻終止，不執(zhí)行 panic 之后的代碼；
- 執(zhí)行 F() 中 defer 函數(shù)，由于沒有 recover，則將 panic 拋到 G() 中；
- 由于 goroutine 內(nèi)部沒有進(jìn)行 recover，則 goroutine 外部函數(shù)，也就是 G() 函數(shù)是沒辦法捕獲的，程序直接崩潰退出。
輸出：
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 類型，所以這樣使用的話會(huì)報(bào)錯(cuò)：
err.Error?undefined?(type?interface?{}?is?interface?with?no?methods)
可以這樣來轉(zhuǎn)換一下：
defer?func()?{
????if?err?:=?recover();?err?!=?nil?{
????????fmt.Println("捕獲異常:",?fmt.Errorf("%v",?err).Error())
????}
}()
panic("a")
或者直接打印結(jié)果：
defer?func()?{
????if?err?:=?recover();?err?!=?nil?{
????????fmt.Println("捕獲異常:",?err)
????}
}()
panic("a")
輸出：
捕獲異常: a
以上就是本文的全部內(nèi)容，其實(shí)寫過其他的語言的同學(xué)都知道，關(guān)閉文件句柄，釋放鎖等操作是很容易忘的。而 Go 語言通過 defer 很好地解決了這個(gè)問題，但在使用過程中還是要小心。
源碼地址：https://github.com/yongxinz/gopher/tree/main/sc
以上就是Go程序員踩過的defer坑錯(cuò)誤處理的詳細(xì)內(nèi)容，更多關(guān)于Go defer錯(cuò)誤處理的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
這篇文章主要介紹了golang分層測試之http接口測試入門教程，小編覺得挺不錯(cuò)的，現(xiàn)在分享給大家，也給大家做個(gè)參考。一起跟隨小編過來看看吧2018-12-12
Go可變參數(shù)函數(shù)的實(shí)現(xiàn)
可變參數(shù)函數(shù)是指函數(shù)參數(shù)的某個(gè)參數(shù)可有可無,即這個(gè)參數(shù)的個(gè)數(shù)可以為0會(huì)多個(gè),可變參數(shù)函數(shù)參數(shù)在日常編程中大量使用,本文主要介紹了Go可變參數(shù)函數(shù)的實(shí)現(xiàn),感興趣的可以了解一下2023-12-12
這篇文章主要介紹了如何使用proto組件編譯pb.go文件的詳細(xì)過程詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-10-10
這篇文章主要介紹了使用go操作redis的有序集合(zset)，具有很好的參考價(jià)值，希望對(duì)大家有所幫助。一起跟隨小編過來看看吧2020-12-12
本文主要介紹了Go 每日一庫之termtables的使用，termtables處理表格形式數(shù)據(jù)的輸出。是一個(gè)很小巧的工具庫。具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2021-07-07
Golang實(shí)踐之Error創(chuàng)建和處理詳解
在 C#、Java 等語言中常常使用 try...catch的方式來捕獲異常,但是在Golang 對(duì)于錯(cuò)誤處理有不同的方式,像網(wǎng)上也有很多對(duì) error 處理的最佳實(shí)踐的文章,其中很多其實(shí)就是對(duì) error 的統(tǒng)一封裝,使用規(guī)范進(jìn)行約束,本文主要是記錄自己對(duì)處理 Error 的一些認(rèn)識(shí)和學(xué)習(xí)2023-09-09
這篇文章主要為大家介紹了GO文件創(chuàng)建及讀寫操作示例詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步早日升職加薪2022-04-04
本文主要介紹了Golang中的深拷貝與淺拷貝使用，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-04-04
本文給大家分享的是一則使用golang實(shí)現(xiàn)文件上傳的代碼，主要是使用os.Create創(chuàng)建文件，io.Copy來保存文件，思路非常清晰，這里推薦給大家，有需要的小伙伴參考下吧。2015-03-03
golang?自帶的map不是并發(fā)安全的,并發(fā)讀寫會(huì)報(bào)錯(cuò),所以下面這篇文章主要給大家介紹了關(guān)于Go語言中map使用和并發(fā)安全的相關(guān)資料,文中通過實(shí)例代碼介紹的非常詳細(xì),需要的朋友可以參考下2022-07-07