Go 錯誤處理：用 select-case 來解決這個歷史難題？
大家好，我是煎魚。
日常看 Go 社區的一些新動態，發現大家對於錯誤處理的新提案是很積極。上次分享了一篇想要用 switch-case 來解決現狀的新提案，不少同學認爲不可行。
沒想到 Go 社區的同學腦洞還是很大的，這幾天又整出來個 select-case 的新提案的方式來解決錯誤處理。
今天基於此給大家分享一下社區裏的新腦洞。
快速背景
本節的背景主要是給不瞭解的同學拉通一下。如果已經知道的可以跳過本節。新提案的提出背景，與之前的類似。
社區內的 Go 開發者很多嫌棄 if err != nil 的錯誤處理方式過於繁瑣，紛紛提出各種改進方式和新提案。截至目前暫無大改進被通過。
具體演示代碼如下：
func CopyFile(src, dst string) error {
r, err := os.Open(src)
if err != nil {
return err
}
defer r.Close()
w, err := os.Create(dst)
if err != nil {
return err
}
defer w.Close()
if _, err := io.Copy(w, r); err != nil {
return err
}
if err := w.Close(); err != nil {
return err
}
// 和煎魚一起煎個魚...
}要寫比較多的判斷和返回錯誤的邏輯，並且這些代碼比正式的調用代碼還要多。所以也常被人戲稱一個 Go 工程裏 80% 都是 if err != nil 等錯誤檢查代碼。
新提案
本次新提案是由 @bjorndm 提出的 《proposal: Go 2: add trap on direct assignment with select block[1]》：
提出者本身使用編程語言的經驗比較豐富，用過：C, Ruby, Pascal, Basic, Java, Shell 等。本次提出該提案的原因是某些 shell 中 trap 語句的啓發。
抽象了一下，提案內容如下：
-
功能上是要擴展 select 關鍵字的語法，允許在 select 關鍵字和其代碼塊之間放一個單獨的變量，這會在變量上安裝一個 “陷阱”（類似觸發器）。
-
這個 “陷阱” 是關鍵點，當任何值被賦給該變量時將會觸發。然後在 select 代碼塊的主體中，case 語句可用於檢查變量的值。
從原作者的描述來看，提案內容比較生硬。我們結合演示代碼來看就知道，他是想構思什麼新語法來使用 select-case 達到錯誤處理的目的了。
演示代碼如下：
func CanFail(name string) error {
var err error
select err {
case err != nil:
return fmt.Errorf("CanFail: %w", err)
}
fin, err := os.Open(name)
buf, err := io.ReadAll(fin)
return nil
}結合新提案的語法，由於 select 代碼塊中是一個變量，符合新語法 “陷阱” 的場景。
因此 err 變量被安裝了 “陷阱”，當後面的 os.Open 和 io.ReadAll 等方法賦值給 err 變量時，就能觸發 select 子句的 case 檢查。
最終以此達到簡化 if err != nil 的目的。也可以滿足 Go1 兼容性保障，達到向前和向後兼容，不需要新增關鍵字。
總結
截止目前我們已經看過了許多 Go 錯誤處理的腦洞新提案。本提案是期望利用 select-case 的特性結構來做擴展，以此達到向前兼容的目的。
從編譯和運行上，作者認爲代價是比較小的，只需要在內部替換成類似 switch 的效果就可以了。
參考資料
[1]
proposal: Go 2: add trap on direct assignment with select block: https://github.com/golang/go/issues/66161
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/iuzDw7_w20jtjJUlynv9NA