大家好，我是煎魚。

之前每次寫 Go 錯誤處理的相關(guān)提案時，大家都會在評論區(qū)探討到一個事。

Go 這活不得勁，常被戲稱，一個大型 Go 工程項(xiàng)目里 60% 的代碼都是 if err != nil。

咱們錯誤處理怎么不借鑒一下 Rust，高低也整個問號的語法特性，就可以簡化這三行了，不香嗎？

借鑒 Rust 用 ？！| 符號

核心的點(diǎn)是在現(xiàn)有的 Go 例子中，我們一般要寫 if err != nil，多了之后又多又雜看起來還有些麻煩。

如下 Go 代碼：

count, err = fd.Write(bytes)
if err != nil {
    return nil, err
}

如果我們也借鑒 Rust 使用 ! 和 ？的簡化版，我們可以演進(jìn)為如下代碼：

count := fd.Write!(bytes)

count := fd.Write(bytes)!

count := fd.Write(bytes)?

也有大佬提到可以演進(jìn)一下使用 || 變成：

fd.Write(bytes) || Expr

不管如何，就是不需要寫三行的 if err != nil 去處理這個硬邏輯，只要加個符號（類似語法糖）就行，由編譯器和運(yùn)行時自己去處理就完了。

這類提案都會被拒絕

為什么最后 Go 沒有落地呢？

普遍社區(qū)中參與討論的大佬認(rèn)為，新的語法糖相較 if err != nil，會增加認(rèn)知和理解代碼的開銷，并降低代碼可讀性。

這些神奇的的功能和符號，他們是隱秘的，更容易讓人錯過，會導(dǎo)致程序控制流邏輯發(fā)生改變，增加程序員的心智負(fù)擔(dān)。

Go 初學(xué)者也需要額外掌握這幾個符號的理解和應(yīng)用，有新的學(xué)習(xí)成本。

這類提案會被直接拒絕，請大家不要再幻想了。

希望開發(fā)者自己定模板

如果只是為了解決那 3 行代碼，部分大佬表示 Go 開發(fā)者應(yīng)該自己定義錯誤模板。而不是借助引入更多的新語法來解決，這也不符合 Go 語言對 “l(fā)ess is more” 的理念定義。

從現(xiàn)在對 Go 錯誤處理的多個提案討論和社區(qū)交流來看，Go 在這塊已經(jīng)陷入僵局，很像工作中的什么呢？

像我們常提的既要也要還要，重要的是這事 ROI 也不夠高，導(dǎo)致Go 核心團(tuán)隊(duì)的動力不足，也不想互相得罪了。

只能甩出一句經(jīng)典：”?讓 Rust 特性留給 Rust“。

總結(jié)

Go 錯誤處理 if err != nil 的解決，已經(jīng)成為了一塊燙手的山芋，怎么改都不討好了，相關(guān)負(fù)責(zé)人積極討論，實(shí)施持續(xù)擺爛中，沒有新的建設(shè)。

根據(jù)以往在依賴管理的，我猜測最終大概率會由 Go 團(tuán)隊(duì)大當(dāng)家 Russ Cox 操刀，否則很難有人能力挽狂瀾。不過，目前來看他對此并不感興趣。對于開啟 Go 工具鏈遙測的提案，也剛吃了閉門羹。

錯誤處理的碰撞，真是 Go 的一生之?dāng)场?/p>