這個新 Go 錯誤處理提案，能解決問題不？
大家好，我是煎魚。
Go 語言的一大特色就是它的錯誤機制，因此基本上所有的錯誤處理提案或討論我都會有所查看和學習，開拓不同的思考視野和解決方法。
今天分享的是 @Cristo García[1] 所提出的提案《Simple Error Handling for Go 2[2]》，略有修改，和煎魚一起學習和討論吧！
Go 必須仍然是 Go
這一個提案的核心觀點是 Go 必須仍然是 Go，這意味著對于錯誤處理的改造需要滿足如下原則：
增加盡可能少的語法。
- 盡可能明確方便。
- 本文中的 “我“ 均指代提案作者 @Cristo García，并非正在學習的煎魚。
原想法
原提案作者 @PeterRk 提出了以下思想：
func getDivisorFromDB(key string) (uint, error) {
//...
}
func GetDivisor(key string) (uint, error) {
exit := func(err error) (uint, error) {
return 1, fmt.Errorf("fail to get divisor with key \"%s\": %v", key, err)
}
divisor := check(getDivisorFromDB(key), exit)
//...
return divisor, nil
}
使用示例：
divisor := check(getDivisorFromDB(key), exit)
等同于現有的：
divisor, err := getDivisorFromDB(key)
if err != nil {
return exit(err) //return err
}
注意看 check 函數，第二個參數的 exit 函數是它 if err != nil 后的回調方法，用于出現 err 時的錯誤處理。
提案作者認為這是一個正確的方向，我們可以改進它（言外之意：現在的還不夠好）。
問題是什么
原有的這個想法，有如下兩個問題：
- 包含不明確的返回語句。
- 有時抽象是不必要的，并且使代碼更難閱讀。
新想法
為此新的想法需要解決以上兩個問題，@Cristo García 期望達到更好的效果。通過對語法的簡單修改，我們新增 or 關鍵字。
可以得到以下示例：
divisor, err := getDivisorFromDB(key) or return exit(err)
新增加的 or 關鍵字將會檢測最后返回的值（必須是錯誤類型）是否與 nil 不同。若不同，將執行右邊的函數。
我們也可以省略 return，代碼將繼續執行。它將像在常規 Go 代碼中一樣被丟棄，這樣該函數就更可重用。
如下示例：
func GetDivisor(key string) (divisor uint, err error) {
divisor, err = getDivisorFromDB(key) or return
return
}
也就是 or return 語句后不跟任何東西，是可以的，會默認拋棄掉。
特殊場景：defer
本節只是為了辯論，但我們可以借此機會為 defer 添加錯誤檢查，看看能不能做一些什么，得到新的處理方式。
核心思路：如果我們能不把返回的錯誤保存在一個變量中，并在 defer 中使之或得到觸發，那么會非常的有意思。
如下示例 1：
defer f.Close() or return errHdl("", fmt.Errorf("couldn't close file"))
不主動顯式聲明變量，若返回值是錯誤類型且不等于 nil，則自動調用 or return 右側的函數并進行處理。
如下示例 2：
defer err := f.Close() or return errHdl("couldn't close file", err)
定義接受錯誤的變量 err 變量，能通過 or return 的語法直接傳參進入函數 errHdl 的入參中被使用。
結果
新增了新的 or return 語法后再與原有的錯誤處理機制進行對比，看看如何。
新的：
func Foo(path string) ([]byte, error) {
errHdlr := func(reason string, err error) ([]byte, error) {
return nil, fmt.Errorf("foo %s %w", reason, err)
}
f, err := os.Open(path) or return errHdlr("couldn't open file", err)
defer f.Close() or return errHdl("", fmt.Errorf("couldn't close file"))
result, err := io.ReadAll(f) or return errHdlr("couldn't read from file " + path, err)
return result, nil
}
舊的：
func Foo(path string) ([]byte, error) {
f, err := os.Open(path)
if err != nil {
return nil, fmt.Errorf("foo %s %w", "couldn't open file", err)
}
result, err := io.ReadAll(f)
if err != nil {
return nil, fmt.Errorf("foo %s %w", "couldn't read from file " + path, err)
}
err = f.Close()
if err != nil {
return nil, fmt.Errorf("foo %s %w", "couldn't close the file " + path, err)
}
return result, nil
}
這是一個非常簡單的例子，但我們已經可以看到其好處。正在閱讀代碼的程序員甚至可以把注意力放在左邊而忽略錯誤處理。
在使用 gofmt 格式化代碼后，也比較美觀。
如下示例：
f, err := os.Open(path) or return errHdlr("couldn't open file", err)
defer f.Close() or return errHdl("", fmt.Errorf("couldn't close file"))
result, err := io.ReadAll(f) or return errHdlr("couldn't read from file " + path, err)
對的很齊。
總結
在這一個新提案中，作者正在做意見征集的階段。其主要是推行了 or 關鍵字和變量可傳遞至右側函數等多種思路（前段時間我還分享了個左側函數和表達式的提案）。
該作者的目的是想盡可能的方便，并且不寫以往被大家吐槽的 if err != nil，實現更加的簡潔。
你覺得這個提案怎么樣呢？歡迎在評論區交流和討論。
參考資料
[1]Cristo García: https://gist.github.com/GGCristo
[2]Simple Error Handling for Go 2: https://gist.github.com/GGCristo/27c33308a07c1be216542f1005792c2b
