試試動 Go recover 刀子,看看能不能優(yōu)化錯誤處理?
大家好,我是煎魚。
Go 的錯誤處理一直是表現(xiàn)最突出的一塊地方,許許多多的同學都提出了各種提案,例如:引入 try-catch、用 panic 代替 if err != nil、引入新的關鍵字等。但這些都被一一駁回了。
不過社區(qū)依然還沒放棄,周末看到有一個新的提案《proposal: runtime: add parameters to recover to only return specific types[1]》挺有意思。
今天就由煎魚帶大家一起學習。
語法說明
Go 的 panic、recover、defer 的基本使用方式。如下代碼:
package main
import "fmt"
func mayPanic() {
panic("a problem")
}
func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered. Error:\n", r)
}
}()
mayPanic()
fmt.Println("After mayPanic()")
}
輸出結果:
Recovered. Error:
a problem
新提案
由于有 Go1 兼容性保障,新提案是在原有的 recover 函數(shù)上動小手術。希望可以現(xiàn)在運行時的 recover 中加入?yún)?shù),僅支持返回特定的類型。
函數(shù)簽名:
recover(except ...interface{})
案例代碼:
defer func(){
if err := recover(&MyError{}, &HelloError{}); err != nil {
switch e := err.(type) {
case *MyError:
fmt.Println(e)
case *HelloError:
fmt.Println(e)
}
}
}
上面代碼中,recover 函數(shù)只支持傳入 MyError 和 HelloError 的指針類型。再在處理邏輯中根據(jù)所傳入的錯誤類型,進行斷言分類,實際上去做不同的邏輯處理。
重點就是限定 recover 入?yún)㈩愋汀?/p>
討論
有些小伙伴可能發(fā)現(xiàn)了,對比看看 PHP 的 try-catch 的用法,與前面的提案代碼是不是有好幾分神似呢?
如下代碼:
try {
...
}
catch (Exception $e) {
echo $e->getMessage();
}
catch (InvalidArgumentException $e) {
echo $e->getMessage();
}
catch (BarException $ex)
{
echo $e->getMessage();
}
catch (FooException $ex)
{
echo $e->getMessage();
}
本質(zhì)上這個新的提案是想在不破壞 Go1 兼容性的情況下,在 Go 中實現(xiàn) try-catch 的方式。
社區(qū)在交流時,也發(fā)現(xiàn)了用戶在現(xiàn)有機制下可以自主實現(xiàn) Go 的類 try-catch 的模式。
如下代碼:
func Recover(expect ...interface{}) interface{} {
if err := recover(); err != nil {
if len(expect) == 0 {
return err
}
rv1 := reflect.Indirect(reflect.ValueOf(err))
for _, e := range expect {
rv2 := reflect.Indirect(reflect.ValueOf(e))
if rv1.Type() == rv2.Type() {
return err
}
}
panic(err)
}
return nil
}
這個自制方法的問題是每次 Recover panic 都會將堆棧深度增加 2。因此還是寄希望于 Go 官方能夠在運行時支持。
在 Go 標準庫的用途對比上,也有產(chǎn)生一定的作用,其涉及到的代碼基本為:
標準庫中至少有以下地方可以復用:
- text/template/exec.go[2]
- go/parser/interface.go[3]
- go/types/check.go[4]
- go/ast/print.go[5]
- encoding/json/encode.go[6]
- encoding/gob/error.go[7]
總結
這個提案本質(zhì)上是希望通過在 recover 函數(shù)中增加入?yún)⒖刂?,再配合?nèi)部邏輯實現(xiàn)類似 Go 版本的 try-catch 的錯誤處理機制模型,且實際在 Go 標準庫中有復用的空間。
但現(xiàn)階段該提案也是贊同和反對參半,也有人認為可以用戶自己實現(xiàn),那就沒必要加大復雜度,去做這個收益不夠大的實現(xiàn)。
你覺得這能補全 Go 錯誤處理的一些機制缺陷嗎?
參考資料
[1]proposal: runtime: add parameters to recover to only return specific types: https://github.com/golang/go/issues/50424
[2]text/template/exec.go: https://cs.opensource.google/go/go/+/refs/tags/go1.17.5:src/text/template/exec.go;l=156
[3]go/parser/interface.go: https://cs.opensource.google/go/go/+/refs/tags/go1.17.5:src/go/parser/interface.go;l=97
[4]go/types/check.go: https://cs.opensource.google/go/go/+/refs/tags/go1.17.5:src/go/types/check.go;l=235
[5]go/ast/print.go: https://cs.opensource.google/go/go/+/refs/tags/go1.17.5:src/go/ast/print.go;l=53
[6]encoding/json/encode.go: https://cs.opensource.google/go/go/+/refs/tags/go1.17.5:src/encoding/json/encode.go;l=317
[7]encoding/gob/error.go: https://cs.opensource.google/go/go/+/refs/tags/go1.17.5:src/encoding/gob/error.go;l=32