對 Go2 錯誤處理提案的批判
復習語法
在 2018 年 8 月，官方正式公布了 Go 2 Draft Designs[2]，其中包含泛型和錯誤處理機制改進的初步草案：
Go 2 Draft Designs
下面是關鍵的 Go2 錯誤處理新語法。
錯誤處理（Error Handling）
第一個要解決的問題就是大量 if err != nil 的問題，針對此提出了 Go2 error handling[3] 的草案設計。
簡單例子：
if err != nil {
return err
}
優化后的方案如下：
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
}
主函數：
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? 關鍵字，用于定義錯誤處理程序流轉，逐級上拋，依此類推，直到處理程序執行 return 語句，才正式結束。
錯誤值打印（Error Printing）
第二個要解決的問題是錯誤值（Error Values）、錯誤檢查（Error Inspection）的問題，其引申出錯誤值打印（Error Printing）的問題，也可以認為是錯誤格式化的不便利。
官方針對此提出了提出了 Error Values[4] 和 Error Printing[5] 的草案設計。
簡單例子如下：
if err != nil {
return fmt.Errorf("write users database: %v", err)
}
優化后的方案如下：
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 沒有實現 %+v 輸出調用堆棧的需求（沒有調用棧，排查問題會很苦惱），因為此舉會破壞 Go1 兼容性和產生一些性能問題，大概會在 Go2 加入。
對提案批判
目標較為模糊
在 Go2 新錯誤處理的提案和草案中，@Liam Breck 認為其沒有去討論根本的需求。僅有一個簡短的目標部分，如下四點：
- 占用空間小的錯誤檢查。
- 對開發人員友好的錯誤處理。
- 顯式檢查和處理錯誤。
- 保證現有 Go1 代碼的兼容性。
更也沒有提到未來可能的擴展性，只是純粹的滿足當下的訴求。這類是模糊的，在激發新的設計思路上有局限性。
無法統一錯誤處理
在真實的應用中，一個函數使用兩種及以上的重復錯誤處理方式是非常常見的。
如下代碼：
// 方式 1
{ debug.PrintStack(); log.Fatal(err) }
// 方式 2
{ log.Println(err) }
// 方式 3
{ if err == io.EOF { break } }
// 方式 4
{ conn.Write([]byte("oops: " + err.Error())) } // network server
新提案中，check 和 handle 函數并不提供多種處理錯誤的途徑。這是一個明顯的遺漏，也沒法統一錯誤處理機制。
如此的話，check 和 handle 就完全是只加了一種新的方式，讓原本的錯誤處理機制更加的繁雜。
混用 err != nil 和 check
handle 函數是后進先出的模式，只能從一個函數中跳出。也就是說它不能很友好的處理可恢復的錯誤內容。
但實際上，許多方法返回錯誤是很常見的。因此我們需要同時使用 err!= nil 和 check，顯得非常的繁瑣。
如下代碼：
handle err { ... }
v, err := f()
if err != nil {
if isBad(err) {
check err
}
// recovery code
}
又是 if err != nil，又是 handle，又是 check 函數。
嵌套 check 更復雜
通過 check 函數，對返回錯誤的函數調用進行嵌套調用，將會模糊了操作的順序。
雖然在大多數情況下，錯誤發生時的調用順序應該是清楚的，但在 check 函數下會顯得不如 if err != nil 清晰。
如下代碼：
check step4(check step1(), check step3(check step2())
另外嵌套代碼會助長不可讀的結構：
f1(v1, check f2(check f3(check f4(v4), v3), check f5(v5))
現在回顧一下，該語言禁止。
f(t ? a : b) 和 f(a++)
是不是顯得有些諷刺呢？
if err != nil 太好用
Go1 的錯誤處理程序太友好了，也就是：
if err != nil {
...
}
其挫敗了 "提高開發人員編寫錯誤處理程序的可能性" 的目標，它使得在沒有上下文信息的情況下返回錯誤是很容易的。會降低對 handle、check 函數的使用頻率，變成一個可有可無的東西。
注：個人感覺，這一點既像黑又像粉...原作者反串黑？當然，確實 if err != nil 很好上手。
復雜的錯誤鏈
對于下面的例子，看看它的感覺...
如下代碼：
func f() error {
handle err { return ... } // finally this
if ... {
handle err { ... } // not that
for ... {
handle err { ... } // nor that
...
}
}
handle err { ... } // secondly this
...
if ... {
handle err { ... } // not that
...
} else {
handle err { ... } // firstly this
check thisFails() // trigger
}
}
顯然，這段代碼是 “難以捉摸” 的，我們必須用眼睛解析整個函數，理解整個錯誤處理的流程和順序。
將會加大我們對程序的認知負擔。
總結
通過對 Go2 錯誤處理的設計草案的復習，我們了解到了 check 和 handle 函數的用法和思路。再針對新的語法，又對可能發生的新問題進行了 “批判”。
總的來說，新的語法，在弊端上會增加既有的代碼復雜度和可讀性，可以引發各種奇怪的嵌套，還會與 if err != nil 產生重復，變成了一種新的處理方式（多了一種）。
是否會還不如 if err != nil 那么的純粹？
參考資料
[1]Golang, how dare you handle my checks!:
[2]Go 2 Draft Designs: https://go.googlesource.com/proposal/+/master/design/go2draft.md
[3]Go2 error handling: https://github.com/golang/proposal/blob/master/design/go2draft-error-handling-overview.md
[4]Error Values: https://github.com/golang/proposal/blob/master/design/go2draft-error-values-overview.md
[5]Error Printing: https://github.com/golang/proposal/blob/master/design/go2draft-error-printing.md
