先睹为快，Go2 Error 的挣扎之路
大家好，我是煎魚。
自從 Go 語言在國內(nèi)火熱以來，除去泛型，其次最具槽點(diǎn)的就是 Go 對錯誤的處理方式，一句經(jīng)典的 if err != nil ?暗號就能認(rèn)出你是一個 Go 語言愛好者。
err 里藏的是什么自然，大家對 Go error 的關(guān)注度更是高漲，Go team 也是，因此在 Go 2 Draft Designs 中正式提到了 error handling（錯誤處理）的相關(guān)草案，希望能夠在未來正式的解決這個問題。
在今天這篇文章中，我們將一同跟蹤 Go2 error，看看他是怎么 “掙扎” 的，能不能破局？
為什么要吐槽 Go1
要吐槽 Go1 error，就得先知道為什么大家到底是在噴 Error 哪里處理的不好。在 Go 語言中，error 其實(shí)本質(zhì)上只是個 Error 的 interface：
type?error?interface?{Error()?string }實(shí)際的應(yīng)用場景如下：
func?main()?{x,?err?:=?foo()if?err?!=?nil?{//?handle?error} }單純的看這個例子似乎沒什么問題，但工程大了后呢？
顯然 if err != nil 的邏輯是會堆積在工程代碼中，Go 代碼里的 if err != nil 甚至?xí)_(dá)到工程代碼量的 30% 以上：
func?main()?{x,?err?:=?foo()if?err?!=?nil?{//?handle?error}y,?err?:=?foo()if?err?!=?nil?{//?handle?error}z,?err?:=?foo()if?err?!=?nil?{//?handle?error}s,?err?:=?foo()if?err?!=?nil?{//?handle?error} }暴力的對比一下，就發(fā)現(xiàn)四行函數(shù)調(diào)用，十二行錯誤，還要苦練且精通 IDE 的快速折疊功能，還是比較麻煩的。
另外既然是錯誤處理，那肯定不單單是一個 return err 了。在工程實(shí)踐中，項(xiàng)目代碼都是層層嵌套的，如果直接寫成：
if?err?!=?nil?{return?err }在實(shí)際工程中肯定是不行。你怎么知道具體是哪里拋出來的錯誤信息，實(shí)際出錯時(shí)只能瞎猜。大家又想出了 PlanB，那就是加各種描述信息：
if?err?!=?nil?{logger.Errorf("煎魚報(bào)錯 err：%v",?err)return?err }雖然看上去人模人樣的，在實(shí)際出錯時(shí)，也會遇到新的問題，因?yàn)槟阋ゲ檫@個錯誤是從哪里拋出來的，沒有調(diào)用堆棧，單純幾句錯誤描述是難以定位的。
這時(shí)候就會發(fā)展成到處打錯誤日志：
func?main()?{err?:=?bar()if?err?!=?nil?{logger.Errorf("bar err：%v",?err)}... }func?bar()?error?{_,?err?:=?foo()if?err?!=?nil?{logger.Errorf("foo err：%v",?err)return?err}return?nil }func?foo()?([]byte,?error)?{s,?err?:=?json.Marshal("hello?world.")if?err?!=?nil?{logger.Errorf("json.Marshal err：%v",?err)return?nil,?err}return?s,?nil }雖然到處打了日志，就會變成錯誤日志非常多，一旦出問題，人肉可能短時(shí)間內(nèi)識別不出來。
最常見的就是到 IDE 上 ctrl + f 搜索是在哪出錯。同時(shí)在實(shí)際應(yīng)用中我們會自定義一些錯誤類型，在 Go 則需要各種判斷和處理：
if?err?:=?dec.Decode(&val);?err?!=?nil?{if?serr,?ok?:=?err.(*json.SyntaxError);?ok?{...}return?err }你得判斷不等于 nil，還得對自定義的錯誤類型進(jìn)行斷言，整體來講比較繁瑣。
匯總來講，Go1 錯誤處理的問題至少有：
在工程實(shí)踐中，if err != nil 寫的煩，代碼中一大堆錯誤處理的判斷，占了相當(dāng)?shù)谋壤?#xff0c;不夠優(yōu)雅。
在排查問題時(shí)，Go 的 err 并沒有其他堆棧信息，只能自己增加描述信息，層層疊加，打一大堆日志，排查很麻煩。
在驗(yàn)證和測試錯誤時(shí)，要自定義錯誤（各種判斷和斷言）或者被迫用字符串校驗(yàn)。
Go1.13 的挽尊
在 2019 年 09 月，Go1.13 正式發(fā)布。其中兩個比較大的兩個關(guān)注點(diǎn)分別是包依賴管理 Go modules 的轉(zhuǎn)正，以及錯誤處理 errors 標(biāo)準(zhǔn)庫的改進(jìn)：
Error wrapping在本次改進(jìn)中，errors 標(biāo)準(zhǔn)庫引入了 Wrapping Error 的概念，并增加了 Is/As/Unwarp 三個方法，用于對所返回的錯誤進(jìn)行二次處理和識別。
同時(shí)也是將 Go2 error 預(yù)規(guī)劃中沒有破壞 Go1 兼容性的相關(guān)功能提前實(shí)現(xiàn)了。
簡單來講，Go1.13 后 Go 的 error 就可以嵌套了，并提供了三個配套的方法。例子：
func?main()?{e?:=?errors.New("腦子進(jìn)煎魚了")w?:=?fmt.Errorf("快抓住：%w",?e)fmt.Println(w)fmt.Println(errors.Unwrap(w)) }輸出結(jié)果：
$?go?run?main.go 快抓住：腦子進(jìn)煎魚了 腦子進(jìn)煎魚了在上述代碼中，變量 w 就是一個嵌套一層的 error。最外層是 “快抓住：”，此處調(diào)用 %w 意味著 Wrapping Error 的嵌套生成。因此最終輸出了 “快抓住：腦子進(jìn)煎魚了”。
需要注意的是，Go 并沒有提供 Warp 方法，而是直接擴(kuò)展了 fmt.Errorf 方法。而下方的輸出由于直接調(diào)用了 errors.Unwarp 方法，因此將 “取” 出一層嵌套，最終直接輸出 “腦子進(jìn)煎魚了”。
對 Wrapping Error 有了基本理解后，我們簡單介紹一下三個配套方法：
func?Is(err,?target?error)?bool func?As(err?error,?target?interface{})?bool func?Unwrap(err?error)?errorerrors.Is
方法簽名：
func?Is(err,?target?error)?bool方法例子：
func?main()?{if?_,?err?:=?os.Open("non-existing");?err?!=?nil?{if?errors.Is(err,?os.ErrNotExist)?{fmt.Println("file?does?not?exist")}?else?{fmt.Println(err)}}}errors.Is 方法的作用是判斷所傳入的 err 和 target 是否同一類型，如果是則返回 true。
errors.As
方法簽名：
func?As(err?error,?target?interface{})?bool方法例子：
func?main()?{if?_,?err?:=?os.Open("non-existing");?err?!=?nil?{var?pathError?*os.PathErrorif?errors.As(err,?&pathError)?{fmt.Println("Failed?at?path:",?pathError.Path)}?else?{fmt.Println(err)}}}errors.As 方法的作用是從 err 錯誤鏈中識別和 target 相同的類型，如果可以賦值，則返回 true。
errors.Unwarp
方法簽名：
func?Unwrap(err?error)?error方法例子：
func?main()?{e?:=?errors.New("腦子進(jìn)煎魚了")w?:=?fmt.Errorf("快抓住：%w",?e)fmt.Println(w)fmt.Println(errors.Unwrap(w)) }該方法的作用是將嵌套的 error 解析出來，若存在多級嵌套則需要調(diào)用多次 Unwarp 方法。
民間自救 pkg/errors
Go1 的 error 處理固然存在許多問題，因此在 Go1.13 前，早已有 “民間” 發(fā)現(xiàn)沒有上下文調(diào)試信息在實(shí)際工程應(yīng)用中存在嚴(yán)重的體感問題。
因此 github.com/pkg/errors 在 2016 年誕生了，該庫也已經(jīng)受到了極大的關(guān)注。
官方例子如下：
type?stackTracer?interface?{StackTrace()?errors.StackTrace }err,?ok?:=?errors.Cause(fn()).(stackTracer) if?!ok?{panic("oops,?err?does?not?implement?stackTracer") }st?:=?err.StackTrace() fmt.Printf("%+v",?st[0:2])?//?top?two?frames//?Example?output: //?github.com/pkg/errors_test.fn //?/home/dfc/src/github.com/pkg/errors/example_test.go:47 //?github.com/pkg/errors_test.Example_stackTrace //?/home/dfc/src/github.com/pkg/errors/example_test.go:127簡單來講，就是對 Go1 error 的上下文處理進(jìn)行了優(yōu)化和處理，例如類型斷言、調(diào)用堆棧等。若有興趣的小伙伴可以自行到 github.com/pkg/errors 進(jìn)行學(xué)習(xí)。
另外你可能會發(fā)現(xiàn) Go1.13 新增的 Wrapping Error 體系與 pkg/errors 有些相像。
你并沒有體會錯，Go team 接納了相關(guān)的意見，對 Go1 進(jìn)行了調(diào)整，但調(diào)用堆棧這塊因綜合原因暫時(shí)沒有納入。
Go2 error 要解決什么問題
在前面我們聊了 Go1 error 的許多問題，以及 Go1.13 和 pkg/errors 的自救和融合。你可能會疑惑，那...Go2 error 還有出場的機(jī)會嗎？即使 Go1 做了這些事情，Go1 error 還有問題嗎？
并沒有解決，if err != nil 依舊一把梭，目前社區(qū)聲音依然認(rèn)為 Go 語言的錯誤處理要改進(jìn)。
Go2 error proposal
在 2018 年 8 月，官方正式公布了 Go 2 Draft Designs，其中包含泛型和錯誤處理機(jī)制改進(jìn)的初步草案：
Go2 Draft Designs注：Go1.13 正式將一些不破壞 Go1 兼容性的 Error 特性加入到了 main branch，也就是前面提到的 Wrapping Error。
錯誤處理（Error Handling）
第一個要解決的問題就是大量 if err != nil 的問題，針對此提出了 Go2 error handling 的草案設(shè)計(jì)。
簡單例子：
if?err?!=?nil?{return?err }優(yōu)化后的方案如下：
func?CopyFile(src,?dst?string)?error?{handle?err?{return?fmt.Errorf("copy?%s?%s:?%v",?src,?dst,?err)}r?:=?check?os.Open(src)defer?r.Close()w?:=?check?os.Create(dst)handle?err?{w.Close()os.Remove(dst)?//?(only?if?a?check?fails)}check?io.Copy(w,?r)check?w.Close()return?nil }主函數(shù)：
func?main()?{handle?err?{log.Fatal(err)}hex?:=?check?ioutil.ReadAll(os.Stdin)data?:=?check?parseHexdump(string(hex))os.Stdout.Write(data) }該提案引入了兩種新的語法形式，首先是 check 關(guān)鍵字，其可以選中一個表達(dá)式 check f(x, y, z) 或 check err，其將會標(biāo)識這是一個顯式的錯誤檢查。
其次引入了 handle 關(guān)鍵字，用于定義錯誤處理程序流轉(zhuǎn)，逐級上拋，依此類推，直到處理程序執(zhí)行 return 語句，才正式結(jié)束。
錯誤值打印（Error Printing）
第二個要解決的問題是錯誤值（Error Values）、錯誤檢查（Error Inspection）的問題，其引申出錯誤值打印（Error Printing）的問題，也可以認(rèn)為是錯誤格式化的不便利。
官方針對此提出了提出了 Error Values 和 Error Printing 的草案設(shè)計(jì)。
簡單例子如下：
if?err?!=?nil?{return?fmt.Errorf("write?users?database:?%v",?err) }優(yōu)化后的方案如下：
package?errorstype?Wrapper?interface?{Unwrap()?error }func?Is(err,?target?error)?bool func?As(type?E)(err?error)?(e?E,?ok?bool)該提案增加了錯誤鏈的 Wrapping Error 概念，并同時(shí)增加 errors.Is 和 errors.As 的方法，與前面說到的 Go1.13 的改進(jìn)一致，不再贅述。
需要留意的是，Go1.13 并沒有實(shí)現(xiàn) %+v 輸出調(diào)用堆棧的需求，因?yàn)榇伺e會破壞 Go1 兼容性和產(chǎn)生一些性能問題，大概會在 Go2 加入。
try-catch 不香嗎
社區(qū)中另外一股聲音就是直指 Go 語言反人類不用 try-catch 的機(jī)制，在社區(qū)內(nèi)也產(chǎn)生了大量的探討，具體可以看看相關(guān)的提案 Proposal: A built-in Go error check function, "try"。
目前該提案已被拒絕，具體可參見 go/issues/32437#issuecomment-512035919 和 Why does Go not have exceptions。
總結(jié)
在這篇文章中，我們介紹了目前 Go1 Error 的現(xiàn)狀，概括了大家對 Go 語言錯誤處理的常見問題和意見。
同時(shí)還介紹了在這幾年間，Go team 針對 Go2、Go1.13 Error 的持續(xù)優(yōu)化和探索。
歡迎評論區(qū)留言：現(xiàn)在 Go2 error proposal 你是否認(rèn)可？為什么？
參考
全成大佬的Golang error 的突圍
為什么 Go 語言的 Error Handling 是一個敗筆
Go語言(golang)新發(fā)布的1.13中的Error Wrapping深度分析
總結(jié)
以上是生活随笔為你收集整理的先睹为快，Go2 Error 的挣扎之路的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 计算机理论高考知识点总结,计算机技能高考
- 下一篇： [机缘参悟-1] - 活在当下，仰望星空