先睹為快，Go2 Error 的掙扎之路
本文轉載自微信公眾號「腦子進煎魚了」，作者陳煎魚 。轉載本文請聯(lián)系腦子進煎魚了公眾號。
大家好，我是煎魚。
自從 Go 語言在國內火熱以來，除去泛型，其次最具槽點的就是 Go 對錯誤的處理方式，一句經(jīng)典的 if err != nil 暗號就能認出你是一個 Go 語言愛好者。
自然，大家對 Go error 的關注度更是高漲，Go team 也是，因此在 Go 2 Draft Designs 中正式提到了 error handling(錯誤處理)的相關草案，希望能夠在未來正式的解決這個問題。
在今天這篇文章中，我們將一同跟蹤 Go2 error，看看他是怎么 “掙扎” 的，能不能破局?
為什么要吐槽 Go1
要吐槽 Go1 error，就得先知道為什么大家到底是在噴 Error 哪里處理的不好。在 Go 語言中，error 其實本質上只是個 Error 的 interface：
- type error interface {
- Error() string
- }
實際的應用場景如下：
- func main() {
- x, err := foo()
- if err != nil {
- // handle error
- }
- }
單純的看這個例子似乎沒什么問題，但工程大了后呢?
顯然 if err != nil 的邏輯是會堆積在工程代碼中，Go 代碼里的 if err != nil 甚至會達到工程代碼量的 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ù)調用，十二行錯誤，還要苦練且精通 IDE 的快速折疊功能，還是比較麻煩的。
另外既然是錯誤處理，那肯定不單單是一個 return err 了。在工程實踐中，項目代碼都是層層嵌套的，如果直接寫成：
- if err != nil {
- return err
- }
在實際工程中肯定是不行。你怎么知道具體是哪里拋出來的錯誤信息，實際出錯時只能瞎猜。大家又想出了 PlanB，那就是加各種描述信息：
- if err != nil {
- logger.Errorf("煎魚報錯 err：%v", err)
- return err
- }
雖然看上去人模人樣的，在實際出錯時，也會遇到新的問題，因為你要去查這個錯誤是從哪里拋出來的，沒有調用堆棧，單純幾句錯誤描述是難以定位的。
這時候就會發(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
- }
雖然到處打了日志，就會變成錯誤日志非常多，一旦出問題，人肉可能短時間內識別不出來。
最常見的就是到 IDE 上 ctrl + f 搜索是在哪出錯。同時在實際應用中我們會自定義一些錯誤類型，在 Go 則需要各種判斷和處理：
- if err := dec.Decode(&val); err != nil {
- if serr, ok := err.(*json.SyntaxError); ok {
- ...
- }
- return err
- }
你得判斷不等于 nil，還得對自定義的錯誤類型進行斷言，整體來講比較繁瑣。
匯總來講，Go1 錯誤處理的問題至少有：
- 在工程實踐中，if err != nil 寫的煩，代碼中一大堆錯誤處理的判斷，占了相當?shù)谋壤粔騼?yōu)雅。
- 在排查問題時，Go 的 err 并沒有其他堆棧信息，只能自己增加描述信息，層層疊加，打一大堆日志，排查很麻煩。
- 在驗證和測試錯誤時，要自定義錯誤(各種判斷和斷言)或者被迫用字符串校驗。
Go1.13 的挽尊
在 2019 年 09 月，Go1.13 正式發(fā)布。其中兩個比較大的兩個關注點分別是包依賴管理 Go modules 的轉正，以及錯誤處理 errors 標準庫的改進：
Error wrapping
在本次改進中，errors 標準庫引入了 Wrapping Error 的概念，并增加了 Is/As/Unwarp 三個方法，用于對所返回的錯誤進行二次處理和識別。
同時也是將 Go2 error 預規(guī)劃中沒有破壞 Go1 兼容性的相關功能提前實現(xiàn)了。
簡單來講，Go1.13 后 Go 的 error 就可以嵌套了，并提供了三個配套的方法。例子：
- func main() {
- e := errors.New("腦子進煎魚了")
- w := fmt.Errorf("快抓住：%w", e)
- fmt.Println(w)
- fmt.Println(errors.Unwrap(w))
- }
輸出結果：
- $ go run main.go
- 快抓住：腦子進煎魚了
- 腦子進煎魚了
在上述代碼中，變量 w 就是一個嵌套一層的 error。最外層是 “快抓住：”，此處調用 %w 意味著 Wrapping Error 的嵌套生成。因此最終輸出了 “快抓住：腦子進煎魚了”。
需要注意的是，Go 并沒有提供 Warp 方法，而是直接擴展了 fmt.Errorf 方法。而下方的輸出由于直接調用了 errors.Unwarp 方法，因此將 “取” 出一層嵌套，最終直接輸出 “腦子進煎魚了”。
對 Wrapping Error 有了基本理解后，我們簡單介紹一下三個配套方法：
- func Is(err, target error) bool
- func As(err error, target interface{}) bool
- func Unwrap(err error) error
errors.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.PathError
- if 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("腦子進煎魚了")
- w := fmt.Errorf("快抓?。?w", e)
- fmt.Println(w)
- fmt.Println(errors.Unwrap(w))
- }
該方法的作用是將嵌套的 error 解析出來，若存在多級嵌套則需要調用多次 Unwarp 方法。
民間自救 pkg/errors
Go1 的 error 處理固然存在許多問題，因此在 Go1.13 前，早已有 “民間” 發(fā)現(xiàn)沒有上下文調試信息在實際工程應用中存在嚴重的體感問題。
因此 github.com/pkg/errors 在 2016 年誕生了，該庫也已經(jīng)受到了極大的關注。
官方例子如下：
- 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 的上下文處理進行了優(yōu)化和處理，例如類型斷言、調用堆棧等。若有興趣的小伙伴可以自行到 github.com/pkg/errors 進行學習。
另外你可能會發(fā)現(xiàn) Go1.13 新增的 Wrapping Error 體系與 pkg/errors 有些相像。
你并沒有體會錯，Go team 接納了相關的意見，對 Go1 進行了調整，但調用堆棧這塊因綜合原因暫時沒有納入。
Go2 error 要解決什么問題
在前面我們聊了 Go1 error 的許多問題，以及 Go1.13 和 pkg/errors 的自救和融合。你可能會疑惑，那...Go2 error 還有出場的機會嗎?即使 Go1 做了這些事情，Go1 error 還有問題嗎?
并沒有解決，if err != nil 依舊一把梭，目前社區(qū)聲音依然認為 Go 語言的錯誤處理要改進。
Go2 error proposal
在 2018 年 8 月，官方正式公布了 Go 2 Draft Designs，其中包含泛型和錯誤處理機制改進的初步草案：
Go2 Draft Designs
注：Go1.13 正式將一些不破壞 Go1 兼容性的 Error 特性加入到了 main branch，也就是前面提到的 Wrapping Error。
錯誤處理(Error Handling)
第一個要解決的問題就是大量 if err != nil 的問題，針對此提出了 Go2 error handling 的草案設計。
簡單例子：
- 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 關鍵字，其可以選中一個表達式 check f(x, y, z) 或 check err，其將會標識這是一個顯式的錯誤檢查。
其次引入了 handle 關鍵字，用于定義錯誤處理程序流轉，逐級上拋，依此類推，直到處理程序執(zhí)行 return 語句，才正式結束。
錯誤值打印(Error Printing)
第二個要解決的問題是錯誤值(Error Values)、錯誤檢查(Error Inspection)的問題，其引申出錯誤值打印(Error Printing)的問題，也可以認為是錯誤格式化的不便利。
官方針對此提出了提出了 Error Values 和 Error Printing 的草案設計。
簡單例子如下：
- if err != nil {
- return fmt.Errorf("write users database: %v", err)
- }
優(yōu)化后的方案如下：
- package errors
- type Wrapper interface {
- Unwrap() error
- }
- func Is(err, target error) bool
- func As(type E)(err error) (e E, ok bool)
該提案增加了錯誤鏈的 Wrapping Error 概念，并同時增加 errors.Is 和 errors.As 的方法，與前面說到的 Go1.13 的改進一致，不再贅述。
需要留意的是，Go1.13 并沒有實現(xiàn) %+v 輸出調用堆棧的需求，因為此舉會破壞 Go1 兼容性和產生一些性能問題，大概會在 Go2 加入。
try-catch 不香嗎
社區(qū)中另外一股聲音就是直指 Go 語言反人類不用 try-catch 的機制，在社區(qū)內也產生了大量的探討，具體可以看看相關的提案 Proposal: A built-in Go error check function, "try"。
目前該提案已被拒絕，具體可參見 go/issues/32437#issuecomment-512035919 和 Why does Go not have exceptions。
總結
在這篇文章中，我們介紹了目前 Go1 Error 的現(xiàn)狀，概括了大家對 Go 語言錯誤處理的常見問題和意見。
同時還介紹了在這幾年間，Go team 針對 Go2、Go1.13 Error 的持續(xù)優(yōu)化和探索。
