關(guān)于 Golang 的錯(cuò)誤處理的討論可以大結(jié)局了

作者：crossoverJie 2025-06-09 08:01:12

在這個(gè)函數(shù)的十行代碼中，只有四行看起來(lái)是有實(shí)際的作用。其余六行看起來(lái)甚至?xí)绊懼饕倪壿嫛Ｋ躁P(guān)于錯(cuò)誤處理的抱怨多年來(lái)一直位居我們年度用戶調(diào)查的榜首也就不足為奇了。

關(guān)于 Go 語(yǔ)言最有爭(zhēng)論的就是錯(cuò)誤處理：

x, err := call()
if err != nil {
        // handle err
}

if err != nil 類似于這樣的代碼非常多，淹沒(méi)了其余真正有用的代碼。這通常發(fā)生在進(jìn)行大量API調(diào)用的代碼中，其中錯(cuò)誤處理很普遍，只是簡(jiǎn)單地返回錯(cuò)誤，有些最終的代碼看起來(lái)像這樣：

func printSum(a, b string) error {
    x, err := strconv.Atoi(a)
    if err != nil {
        return err
    }
    y, err := strconv.Atoi(b)
    if err != nil {
        return err
    }
    fmt.Println("result:", x + y)
    return nil
}

在這個(gè)函數(shù)的十行代碼中，只有四行看起來(lái)是有實(shí)際的作用。其余六行看起來(lái)甚至?xí)绊懼饕倪壿嫛Ｋ躁P(guān)于錯(cuò)誤處理的抱怨多年來(lái)一直位居我們年度用戶調(diào)查的榜首也就不足為奇了。（有一段時(shí)間，缺乏泛型支持超過(guò)了對(duì)錯(cuò)誤處理的抱怨，但現(xiàn)在 Go 已經(jīng)支持泛型了，錯(cuò)誤處理又回到了榜首。）

Go團(tuán)隊(duì)認(rèn)真對(duì)待社區(qū)反饋，因此多年來(lái)我們一直在嘗試為這個(gè)問(wèn)題找到解決方案，并聽(tīng)取 Go 社區(qū)的意見(jiàn)。

Go 團(tuán)隊(duì)的第一次明確嘗試可以追溯到 2018 年，當(dāng)時(shí)Russ Cox正式提到了這個(gè)問(wèn)題[2]，作為我們當(dāng)時(shí)稱為 Go2 努力的一部分。他基于 Marcel van Lohuizen 的草案設(shè)計(jì)[3]概述了一個(gè)可能的解決方案。該設(shè)計(jì)基于check和handle機(jī)制，相當(dāng)全面。草案包括對(duì)替代解決方案的詳細(xì)分析，包括與其他語(yǔ)言采用的方法的比較。如果您想知道您的特定錯(cuò)誤處理想法之前是否被考慮過(guò)，請(qǐng)閱讀這份文檔！

// printSum implementation using the proposed check/handle mechanism.
func printSum(a, b string) error {
    handle err { return err }
    x := check strconv.Atoi(a)
    y := check strconv.Atoi(b)
    fmt.Println("result:", x + y)
    return nil
}

check和handle方法被認(rèn)為過(guò)于復(fù)雜，大約一年后，在2019年，我們推出了更加簡(jiǎn)化的、現(xiàn)在臭名昭著[4]的try提案[5]。它基于 check 和 handle 的思想，但 check 偽關(guān)鍵字變成了try內(nèi)置函數(shù)，handle部分被省略了。為了探索try內(nèi)置函數(shù)的影響，我們編寫(xiě)了一個(gè)簡(jiǎn)單的工具（tryhard[6]），使用try重寫(xiě)現(xiàn)有的錯(cuò)誤處理代碼。這個(gè)提案被激烈爭(zhēng)論，在GitHub問(wèn)題[7]上接近900條評(píng)論。

// printSum implementation using the proposed try mechanism.
func printSum(a, b string) error {
    // use a defer statement to augment errors before returning
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x + y)
    return nil
}

然而，try通過(guò)在出錯(cuò)時(shí)從封閉函數(shù)返回來(lái)影響控制流，并且可能從深度嵌套的表達(dá)式中這樣做，從而隱藏了這種控制流。這使得該提案對(duì)許多人來(lái)說(shuō)難以接受，盡管在這個(gè)提案上投入了大量精力，我們還是決定放棄這項(xiàng)工作。回顧起來(lái)，引入一個(gè)新關(guān)鍵字可能會(huì)更好，這是我們現(xiàn)在可以做的事情，因?yàn)槲覀兺ㄟ^(guò)go.mod文件和特定文件的指令對(duì)語(yǔ)言版本有細(xì)粒度的控制。將try的使用限制在賦值和語(yǔ)句中可能會(huì)緩解一些其他的擔(dān)憂。Jimmy Frasche的最近提案[8]基本上回到了原始的check和handle設(shè)計(jì)，并解決了該設(shè)計(jì)的一些缺點(diǎn)，正朝著這個(gè)方向發(fā)展。

try提案的反響導(dǎo)致了大量的反思，包括Russ Cox的一系列博客文章："關(guān)于Go提案流程的思考"[9]。其中一個(gè)結(jié)論是，我們可能通過(guò)提出一個(gè)幾乎完全成熟的提案，給社區(qū)反饋留下很少的空間，以及一個(gè)"具有威脅性"的實(shí)現(xiàn)時(shí)間表，從而降低了獲得更好結(jié)果的機(jī)會(huì)。根據(jù)"Go提案流程：大型變更"[10]："回顧起來(lái)，try是一個(gè)足夠大的變更，我們發(fā)布的新設(shè)計(jì)應(yīng)該是第二版草案設(shè)計(jì)，而不是帶有實(shí)現(xiàn)時(shí)間表的提案"。但不管在這種情況下可能存在的流程和溝通失敗，用戶對(duì)該提案有著非常強(qiáng)烈地抵觸情緒。

當(dāng)時(shí)我們沒(méi)有更好的解決方案，幾年來(lái)都沒(méi)有為錯(cuò)誤處理追求語(yǔ)法變更。不過(guò)，社區(qū)中的許多人受到了啟發(fā)，我們收到了源源不斷的錯(cuò)誤處理提案，其中許多非常相似，有些有趣，有些難以理解，有些不可行。為了跟蹤不斷擴(kuò)大的提案，一年后，Ian Lance Taylor 創(chuàng)建了一個(gè)總體問(wèn)題[11]，總結(jié)了改進(jìn)錯(cuò)誤處理的提議變更的當(dāng)前狀態(tài)。創(chuàng)建了一個(gè)Go Wiki[12]來(lái)收集相關(guān)的反饋、討論和文章。

關(guān)于錯(cuò)誤處理冗長(zhǎng)性的抱怨持續(xù)存在（參見(jiàn)2024年上半年Go開(kāi)發(fā)者調(diào)查結(jié)果[13]），因此，在Go團(tuán)隊(duì)內(nèi)部提案經(jīng)過(guò)一系列日益完善之后，Ian Lance Taylor 在2024年發(fā)布了"使用?減少錯(cuò)誤處理樣板代碼"[14]。這次的想法是借鑒Rust[15]中實(shí)現(xiàn)的構(gòu)造，特別是?操作符[16]。希望通過(guò)依靠使用既定符號(hào)的現(xiàn)有機(jī)制，并考慮我們多年來(lái)學(xué)到的東西，我們應(yīng)該能夠最終取得一些進(jìn)展。在一小批用戶調(diào)研中，向開(kāi)發(fā)者展示使用 ? 的 Go 代碼時(shí)，絕大多數(shù)參與者正確猜出了代碼的含義，這進(jìn)一步說(shuō)服我們?cè)僭囈淮巍榱四軌蚩吹阶兓挠绊懀琁an 編寫(xiě)了一個(gè)工具，將普通 Go 代碼轉(zhuǎn)換為使用提議的新語(yǔ)法的代碼，我們還在編譯器中對(duì)該功能進(jìn)行了原型設(shè)計(jì)。

// printSum implementation using the proposed "?" statements.
func printSum(a, b string) error {
    x := strconv.Atoi(a) ?
    y := strconv.Atoi(b) ?
    fmt.Println("result:", x + y)
    return nil
}

不幸的是，與其他錯(cuò)誤處理想法一樣，這個(gè)新提案也很快被評(píng)論淹沒(méi)，許多人建議進(jìn)行微調(diào)，通常基于個(gè)人偏好。Ian關(guān)閉了提案，并將內(nèi)容移到了討論區(qū)[17]，以促進(jìn)對(duì)話并收集進(jìn)一步的反饋。一個(gè)稍作修改的版本得到了稍微積極一些[18]的接受，但廣泛的支持仍然難以達(dá)成一致。

經(jīng)過(guò)這么多年的嘗試，Go團(tuán)隊(duì)提出了三個(gè)完整的提案，社區(qū)提出了數(shù)百個(gè)提案，其中大多數(shù)是各類提案的變體，所有這些都未能獲得足夠（更不用說(shuō)壓倒性）的支持，我們現(xiàn)在面臨的問(wèn)題是：如何繼續(xù)？我們是否應(yīng)該繼續(xù)？

我們認(rèn)為不應(yīng)該。

更準(zhǔn)確地說(shuō)，我們應(yīng)該停止嘗試解決_語(yǔ)法問(wèn)題_，至少在可預(yù)見(jiàn)的未來(lái)是這樣。提案流程[19]為這個(gè)決定提供了理由：

提案流程的目標(biāo)是及時(shí)就結(jié)果達(dá)成普遍共識(shí)。如果提案審查無(wú)法在問(wèn)題跟蹤器上的問(wèn)題討論中確定普遍共識(shí)，通常的結(jié)果是提案被拒絕。

沒(méi)有一個(gè)錯(cuò)誤處理提案達(dá)到任何接近共識(shí)的程度，所以它們都被拒絕了。即使是 Google 的 Go 團(tuán)隊(duì)最資深的成員也不一致同意目前最佳的方案（也許在某個(gè)時(shí)候會(huì)改變）。但是沒(méi)有具體的共識(shí)，我們就無(wú)法合理地向前推進(jìn)。

有支持現(xiàn)狀的有效證據(jù)：

? 如果 Go 早期就為錯(cuò)誤處理引入了特定的語(yǔ)法糖，今天幾乎沒(méi)有人會(huì)爭(zhēng)論它。但我們已經(jīng)走過(guò)了15年，機(jī)會(huì)已經(jīng)過(guò)去了，Go 有一種完全合適的錯(cuò)誤處理方式，即使有時(shí)看起來(lái)可能很冗長(zhǎng)。

? 從另一個(gè)角度看，假設(shè)我們今天找到了完美的解決方案。將其納入語(yǔ)言只會(huì)導(dǎo)致從一個(gè)不滿意的用戶群體（支持變更的）轉(zhuǎn)移到另一個(gè)（喜歡現(xiàn)狀的）。當(dāng)我們決定向語(yǔ)言添加泛型時(shí)，我們處于類似的情況，盡管有一個(gè)重要的區(qū)別是：今天沒(méi)有人被迫使用泛型，好的泛型庫(kù)的編寫(xiě)使得用戶可以基本忽略它們是不是泛型，這要?dú)w功于類型推斷。相反，如果向語(yǔ)言添加新的錯(cuò)誤處理語(yǔ)法構(gòu)造，幾乎每個(gè)人都需要開(kāi)始使用它，以免他們的代碼變得不符合最新的范式。

? 不添加額外的語(yǔ)法符合 Go 的設(shè)計(jì)規(guī)則之一：不提供多種做同一件事的方式。在" foot traffic "的領(lǐng)域有這個(gè)規(guī)則的例外：賦值就是一個(gè)例子。具有諷刺意味的是，在短變量聲明[20]（:=）中重新聲明變量的能力是為了解決因錯(cuò)誤處理而產(chǎn)生的問(wèn)題而引入的：沒(méi)有重新聲明，錯(cuò)誤檢查序列需要為每個(gè)檢查使用不同名稱的err變量（或額外的單獨(dú)變量聲明）。當(dāng)時(shí)更好的解決方案可能是為錯(cuò)誤處理提供更多的語(yǔ)法支持。那樣的話，可能就不需要重新聲明規(guī)則了，沒(méi)有它各種相關(guān)的復(fù)雜性[21]也就不存在了。

? 回到實(shí)際的錯(cuò)誤處理代碼，如果錯(cuò)誤得到處理，冗長(zhǎng)性就會(huì)被淡化。良好的錯(cuò)誤處理通常需要向錯(cuò)誤添加額外信息。例如，用戶調(diào)查中的一個(gè)反復(fù)出現(xiàn)的評(píng)論是關(guān)于缺少與錯(cuò)誤相關(guān)的堆棧信息。這可以通過(guò)生成并返回增強(qiáng)錯(cuò)誤的支持函數(shù)來(lái)解決。在這個(gè)例子中，模板代碼的相對(duì)數(shù)量要小得多：

func printSum(a, b string) error {
    x, err := strconv.Atoi(a)
    if err != nil {
        return fmt.Errorf("invalid integer: %q", a)
    }
    y, err := strconv.Atoi(b)
    if err != nil {
        return fmt.Errorf("invalid integer: %q", b)
    }
    fmt.Println("result:", x + y)
    return nil
}

? 新的標(biāo)準(zhǔn)庫(kù)功能也可以幫助減少錯(cuò)誤處理樣板代碼，這與Rob Pike 2015年的博客文章"錯(cuò)誤就是值"[22]的觀點(diǎn)非常相似。例如在某些情況下，cmp.Or[23]可用于一次處理一系列錯(cuò)誤：

func printSum(a, b string) error {
    x, err1 := strconv.Atoi(a)
    y, err2 := strconv.Atoi(b)
    if err := cmp.Or(err1, err2); err != nil {
        return err
    }
    fmt.Println("result:", x+y)
    return nil
}

? 編寫(xiě)、閱讀和調(diào)試代碼都是完全不同的工作。編寫(xiě)重復(fù)的錯(cuò)誤檢查可能很乏味，但今天的 IDE 提供了強(qiáng)大的、甚至是 LLM 輔助的代碼補(bǔ)全。編寫(xiě)基本的錯(cuò)誤檢查對(duì)這些工具來(lái)說(shuō)很簡(jiǎn)單。在閱讀代碼時(shí)冗長(zhǎng)性最明顯，但工具在這里也可能有所幫助；例如，有 Go 語(yǔ)言設(shè)置的 IDE 可以提供一個(gè)切換開(kāi)關(guān)來(lái)隱藏錯(cuò)誤處理代碼。

? 在調(diào)試錯(cuò)誤處理代碼時(shí)，能夠快速添加println或有一個(gè)專門的行位置來(lái)在調(diào)試器中設(shè)置斷點(diǎn)會(huì)很有幫助。當(dāng)已經(jīng)有專門的if語(yǔ)句時(shí)，這很容易。但如果所有錯(cuò)誤處理邏輯都隱藏在check、try或?后面，代碼可能必須首先更改為普通的if語(yǔ)句，這會(huì)使調(diào)試復(fù)雜化，甚至可能引入一些錯(cuò)誤。

? 還有實(shí)際的考慮：想出一個(gè)新的錯(cuò)誤處理語(yǔ)法想法很容易；因此社區(qū)提出了大量的提案。想出一個(gè)經(jīng)得起審查的好解決方案：就不那么容易了。正確設(shè)計(jì)語(yǔ)言變更并實(shí)際實(shí)現(xiàn)它需要協(xié)調(diào)一致的努力。真正的成本仍然在后面：所有需要更改的代碼、需要更新的文檔、需要調(diào)整的工具。綜合考慮，語(yǔ)法變更非常昂貴，Go 團(tuán)隊(duì)相對(duì)較小，還有很多其他優(yōu)先事項(xiàng)要處理。

? 最后一點(diǎn)，我們中的一些人最近有機(jī)會(huì)參加Google Cloud Next 2025[24]，Go團(tuán)隊(duì)在那里有一個(gè)展位，我們還舉辦了一個(gè)小型的Go聚會(huì)。我們有機(jī)會(huì)詢問(wèn)的每一位Go用戶都堅(jiān)決認(rèn)為我們不應(yīng)該為了更好的錯(cuò)誤處理而改變語(yǔ)言。許多人提到，當(dāng)剛從另一種具有錯(cuò)誤處理支持的語(yǔ)言轉(zhuǎn)過(guò)來(lái)時(shí)，Go中缺乏特定的錯(cuò)誤處理支持最為明顯。隨著人們使用的時(shí)間越來(lái)越久，這個(gè)問(wèn)題變得不那么重要了。這當(dāng)然不是一個(gè)足夠大的代表性人群，但它是我們?cè)?GitHub上看到的不同人群。

當(dāng)然，也有支持變更的理由：

? 缺乏更好的錯(cuò)誤處理支持仍然是我們用戶調(diào)查中最大的抱怨。如果Go團(tuán)隊(duì)真的認(rèn)真對(duì)待用戶反饋，我們最終應(yīng)該為此做些什么。（盡管似乎也沒(méi)有壓倒性的支持[25]語(yǔ)言變更。）

? 也許單一地關(guān)注減少字符數(shù)不是一個(gè)正確的方向。更好的方法可能是使用關(guān)鍵字使默認(rèn)錯(cuò)誤處理高度可見(jiàn)，同時(shí)也要?jiǎng)h除模板代碼（err != nil）。這種方法可能使讀者（代碼審查者）更容易看到錯(cuò)誤被處理了，而不需要"看多次"，從而提高代碼質(zhì)量和安全性。這將使我們回到check和handle的起點(diǎn)。

? 我們真的不知道現(xiàn)在的冗長(zhǎng)問(wèn)題在多大程度上是錯(cuò)誤檢查直接導(dǎo)致的。

盡管如此，迄今為止沒(méi)有任何解決錯(cuò)誤處理的嘗試獲得足夠的支持。如果我們誠(chéng)實(shí)地評(píng)估我們所處的位置，我們只能承認(rèn)我們既沒(méi)有對(duì)問(wèn)題的共同理解，也不是都同意首先存在問(wèn)題。考慮到這一點(diǎn)，我們做出以下符合當(dāng)下的決定：

_在可預(yù)見(jiàn)的未來(lái)，Go團(tuán)隊(duì)將停止為錯(cuò)誤處理追求語(yǔ)法語(yǔ)言變更。我們還將關(guān)閉所有主要涉及錯(cuò)誤處理語(yǔ)法的開(kāi)放和即將提交的提案，不再進(jìn)一步跟進(jìn)。

社區(qū)在探索、討論和辯論這些問(wèn)題上投入了巨大的努力。雖然這可能沒(méi)有導(dǎo)致錯(cuò)誤處理語(yǔ)法的任何變化，但這些努力已經(jīng)為 Go 語(yǔ)言和我們的流程帶來(lái)了許多其他改進(jìn)。也許，在未來(lái)的某個(gè)時(shí)候，關(guān)于錯(cuò)誤處理會(huì)出現(xiàn)更清晰的圖景。在那之前，我們期待著將這種令人難以置信的熱情集中在新的機(jī)會(huì)上，讓Go對(duì)每個(gè)人都變得更好。