### defer陷阱
#### 1. defer 與 closure
~~~
func foo(a, b int) (i int, err error) {
defer fmt.Printf("first defer err %v\n", err)
defer func(err error) { fmt.Printf("second defer err %v\n", err) }(err)
defer func() { fmt.Printf("third defer err %v\n", err) }()
if b == 0 {
err = errors.New("divided by zero!")
return
}
i = a / b
return
}
輸出結果:
third defer err divided by zero!
second defer err <nil>
first defer err <nil>
~~~
解釋:如果 defer 后面跟的不是一個 closure 最后執行的時候我們得到的并不是最新的值
#### 2. defer 與 return
~~~
func foo() (i int) {
i = 0
defer func() {
fmt.Println(i)
}()
return 2
}
輸出結果:
2
~~~
解釋:在有具名返回值的函數中(這里具名返回值為 i),執行 return 2 的時候實際上已經將 i 的值重新賦值為 2。所以defer closure 輸出結果為 2 而不是 1
#### 3. defer nil 函數
~~~
func test() {
var run func() = nil
defer run()
fmt.Println("runs")
}
func main() {
defer func() {
if err := recover(); err != nil {
fmt.Println(err)
}
}()
test()
}
輸出結果:
runs
runtime error: invalid memory address or nil pointer dereference
~~~
解釋:名為 test 的函數一直運行至結束,然后 defer 函數會被執行且會因為值為 nil 而產生 panic 異常。然而值得注意的是,run() 的聲明是沒有問題,因為在test函數運行完成后它才會被調用
#### 4. 在錯誤的位置使用 defer
當 http.Get 失敗時會拋出異常。
~~~
func do() error {
res, err := http.Get("http://www.google.com")
defer res.Body.Close()
if err != nil {
return err
}
// ..code...
return nil
}
輸出結果:
panic: runtime error: invalid memory address or nil pointer dereference
~~~
解釋:因為在這里我們并沒有檢查我們的請求是否成功執行,當它失敗的時候,我們訪問了 Body 中的空變量 res ,因此會拋出異常
#### recover使用誤區
在項目中,有眾多的數據庫更新操作,正常的更新操作需要提交,而失敗的就需要回滾,如果異常分支比較多,
就會有很多重復的回滾代碼,所以有人嘗試了一個做法:即在defer中判斷是否出現異常,有異常則回滾,否則提交。
簡化代碼如下所示:
~~~golang
func IsPanic() bool {
if err := recover(); err != nil {
fmt.Println("Recover success...")
return true
}
return false
}
func UpdateTable() {
// defer中決定提交還是回滾
defer func() {
if IsPanic() {
// Rollback transaction
} else {
// Commit transaction
}
}()
// Database update operation...
}
~~~
`func IsPanic() bool`用來接收異常,返回值用來說明是否發生了異常。`func UpdateTable()`函數中,使用defer來判斷最終應該提交還是回滾。
上面代碼初步看起來還算合理,但是此處的`IsPanic()`再也不會返回`true`,不是`IsPanic()`函數的問題,而是其調用的位置不對
**recover 失效的條件**
上面代碼`IsPanic()`失效了,其原因是違反了recover的一個限制,導致recover()失效(永遠返回`nil`)。
以下三個條件會讓recover()返回`nil`:
1. panic時指定的參數為`nil`;(一般panic語句如`panic("xxx failed...")`)
2. 當前協程沒有發生panic;
3. recover沒有被defer方法直接調用;
本例中,recover() 調用棧為“defer (匿名)函數” –> IsPanic() –> recover()。也就是說,recover并沒有被defer方法直接調用。符合第3個條件,所以recover() 永遠返回nil
- 概述
- go語言基礎特性
- Go語言聲明
- Go項目構建及編譯
- go command
- 程序設計原則
- Go基礎
- 變量
- 常量
- iota
- 基本類型
- byte和rune類型
- 類型定義和類型別名
- 數組
- string
- 高效字符串連接
- string底層原理
- 運算符
- new
- make
- 指針
- 下劃線 & import
- 語法糖
- 簡短變量申明
- 流程控制
- ifelse
- switch
- select
- select實現原理
- select常見案例
- for
- range
- range實現原理
- 常見案例
- range陷阱
- Goto&Break&Continue
- Go函數
- 函數
- 可變參數函數
- 高階函數
- init函數和main函數
- 匿名函數
- 閉包
- 常用內置函數
- defer
- defer常見案例
- defer規則
- defer與函數返回值
- defer實現原理
- defer陷阱
- 數據結構
- slice
- slice內存布局
- slice&array
- slice底層實現
- slice陷阱
- map
- Map實現原理
- 集合
- List
- Set
- 線程安全數據結構
- sync.Map
- Concurrent Map
- 面向對象編程
- struct
- 匿名結構體&匿名字段
- 嵌套結構體
- 結構體的“繼承”
- struct tag
- 行為方法
- 方法與函數
- type Method Value & Method Expressions
- interface
- 類型斷言
- 多態
- 錯誤機制
- error
- 自定義錯誤
- panic&recover
- reflect
- reflect包
- 應用示例
- DeepEqual
- 反射-fillObjectField
- 反射-copyObject
- IO
- 讀取文件
- 寫文件
- bufio
- ioutil
- Go網絡編程
- tcp
- tcp粘包
- udp
- HTTP
- http服務
- httprouter
- webSocket
- go并發編程
- Goroutine
- thread vs goroutine
- Goroutine任務取消
- 通過channel廣播實現
- Context
- Goroutine調度機制
- goroutine調度器1.0
- GMP模型調度器
- 調度器竊取策略
- 調度器的生命周期
- 調度過程全解析
- channel
- 無緩沖的通道
- 緩沖信道
- 單向信道
- chan實現原理
- 共享內存并發機制
- mutex互斥鎖
- mutex
- mutex原理
- mutex模式
- RWLock
- 使用信道處理競態條件
- WaitGroup
- 工作池
- 并發任務
- once運行一次
- 僅需任意任務完成
- 所有任務完成
- 對象池
- 定時器Timer
- Timer
- Timer實現原理
- 周期性定時器Ticker
- Ticker對外接口
- ticker使用場景
- ticker實現原理
- ticker使用陷阱
- 包和依賴管理
- package
- 依賴管理
- 測試
- 單元測試
- 表格測試法
- Banchmark
- BDD
- 常用架構模式
- Pipe-filter pattern
- Micro Kernel
- JSON
- json-內置解析器
- easyjson
- 性能分析
- gc
- 工具類
- fmt
- Time
- builtin
- unsafe
- sync.pool
- atomic
- flag
- runtime
- strconv
- template