建站
咨詢
售后
建站咨詢
新聞中心
大家好，我是煎魚(yú)。
之前每次寫 Go 錯(cuò)誤處理的相關(guān)提案時(shí)，大家都會(huì)在評(píng)論區(qū)探討到一個(gè)事。
Go 這活不得勁，常被戲稱，一個(gè)大型 Go 工程項(xiàng)目里 60% 的代碼都是 if err != nil。
咱們錯(cuò)誤處理怎么不借鑒一下 Rust，高低也整個(gè)問(wèn)號(hào)的語(yǔ)法特性，就可以簡(jiǎn)化這三行了，不香嗎？
借鑒 Rust 用 ？！| 符號(hào)
核心的點(diǎn)是在現(xiàn)有的 Go 例子中，我們一般要寫 if err != nil，多了之后又多又雜看起來(lái)還有些麻煩。
如下 Go 代碼：
count, err = fd.Write(bytes)
if err != nil {
return nil, err
}
如果我們也借鑒 Rust 使用 ! 和 ？的簡(jiǎn)化版，我們可以演進(jìn)為如下代碼：
count := fd.Write!(bytes)
count := fd.Write(bytes)!
count := fd.Write(bytes)?
也有大佬提到可以演進(jìn)一下使用 || 變成：
fd.Write(bytes) || Expr
不管如何，就是不需要寫三行的 if err != nil 去處理這個(gè)硬邏輯，只要加個(gè)符號(hào)（類似語(yǔ)法糖）就行，由編譯器和運(yùn)行時(shí)自己去處理就完了。
這類提案都會(huì)被拒絕
為什么最后 Go 沒(méi)有落地呢？
普遍社區(qū)中參與討論的大佬認(rèn)為，新的語(yǔ)法糖相較 if err != nil，會(huì)增加認(rèn)知和理解代碼的開(kāi)銷，并降低代碼可讀性。
這些神奇的的功能和符號(hào)，他們是隱秘的，更容易讓人錯(cuò)過(guò)，會(huì)導(dǎo)致程序控制流邏輯發(fā)生改變，增加程序員的心智負(fù)擔(dān)。
Go 初學(xué)者也需要額外掌握這幾個(gè)符號(hào)的理解和應(yīng)用，有新的學(xué)習(xí)成本。
這類提案會(huì)被直接拒絕，請(qǐng)大家不要再幻想了。
希望開(kāi)發(fā)者自己定模板
如果只是為了解決那 3 行代碼，部分大佬表示 Go 開(kāi)發(fā)者應(yīng)該自己定義錯(cuò)誤模板。而不是借助引入更多的新語(yǔ)法來(lái)解決，這也不符合 Go 語(yǔ)言對(duì) “l(fā)ess is more” 的理念定義。
從現(xiàn)在對(duì) Go 錯(cuò)誤處理的多個(gè)提案討論和社區(qū)交流來(lái)看，Go 在這塊已經(jīng)陷入僵局，很像工作中的什么呢？
像我們常提的既要也要還要，重要的是這事 ROI 也不夠高，導(dǎo)致Go 核心團(tuán)隊(duì)的動(dòng)力不足，也不想互相得罪了。
只能甩出一句經(jīng)典：”?讓 Rust 特性留給 Rust“。
總結(jié)
Go 錯(cuò)誤處理 if err != nil 的解決，已經(jīng)成為了一塊燙手的山芋，怎么改都不討好了，相關(guān)負(fù)責(zé)人積極討論，實(shí)施持續(xù)擺爛中，沒(méi)有新的建設(shè)。
根據(jù)以往在依賴管理的，我猜測(cè)最終大概率會(huì)由 Go 團(tuán)隊(duì)大當(dāng)家 Russ Cox 操刀，否則很難有人能力挽狂瀾。不過(guò)，目前來(lái)看他對(duì)此并不感興趣。對(duì)于開(kāi)啟 Go 工具鏈遙測(cè)的提案，也剛吃了閉門羹。
錯(cuò)誤處理的碰撞，真是 Go 的一生之?dāng)场?/p>
本文標(biāo)題：Go 為什么不像 Rust 用 ？！做錯(cuò)誤處理？
當(dāng)前URL：http://m.5511xx.com/article/cdscohg.html
