大家好，我是煎魚。

對于 Go 這一門編程語言，Go 核心團隊的成員自己心里也非常有數，持續最久的吐槽就是錯誤處理的冗長。

當然，從我們的角度來看，社區還存在對于 Go 錯誤處理現有機制不滿意的情況。

近期 Go 官方發表了《[ On | No ] syntactic support for error handling[1]》正式宣布對錯誤處理機制的想法和后續表態。今天分享給大家。

Go1 錯誤處理的 “冗長” 例子

Go 的 if err != nil 的最短例子如下：

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

更常見的代碼例子如下：

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
}

這個函數大概只有 10 余行，但是實際上只有 3-4 行在實際上做邏輯調用和處理，剩余的 6 行都在處理 err 變量的冗余。

這樣的冗長，就是為什么有關錯誤處理的吐槽排在每年的 Go 開發者調查報告前列的緣由。

圖片

這樣一看，其實就是 Go1 自帶的錯誤處理方式和機制，就是會被一部份同學瘋狂吐槽的（也有支持的）

圖片

非常見仁見智了。

Go 核心團隊的多輪嘗試

Go 核心團隊瘋狂表示多人在多年做過多輪的積極嘗試。

最早可以追溯到 2018 年，時任團隊負責人的 @Russ Cox 想將該問題的優化放進 Go2 的大籃子里一起解決了。

團隊中的 @Marcel van Lohuizen 提出了《Error Handling — Draft Design[2]》的提案，示例代碼如下：

// 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
}

但，這被認為太復雜。又沒有辦法繼續推進。僵持住了。

隨后在 2019 年，根據新的 try 提案《Proposal: A built-in Go error check function, try[3]》又做了改善。

示例代碼如下：

// 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，以及 try 會打亂控制流的問題。導致許多人我無法接受 try 提案。并成功被稱為：“臭名昭著”。最終被迫放棄。

又經過多年的折騰，@Ian Lance Taylor 參考 Rust 發布了新的提案《proposal: spec: reduce error handling boilerplate using ?[4]》。

示例代碼如下：

// 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
}

實際上 @Ian Lance Taylor 還做了小型的用戶實操實驗，當時絕大部分參與者都能夠意識到 ? 的作用是什么。他才敢放心（有信心）繼續推進。

但是依然很不幸，這個提案依然被很多的建議和想法給淹沒。沒法得出一個最終的最優解。

由此，Go 核心團隊的 10+ 年對于錯誤處理機制探討的推進。被迫暫告一段落。甚至引發了 Go 團隊很多的 “反思”。

最終結論（階段性）

Go 核心團隊認為，其在過去那么多年，一共提出了 3 個成熟的提案和數百個社區提案。但是這些所有的提案，都未能夠得到足夠的社區支持。

最終（2025 年）Go 官方將決定停止嘗試解決錯誤處理機制的問題。給出的理由是提案流程里的：

圖片

“提案流程的目標是及時就結果達成普遍共識。如果提案審查無法在問題跟蹤器上的問題討論中達成普遍共識，通常的結果就是拒絕提案?！?/p>

同時有兩個非常扎心的事實：

• 截止至目前，沒有任何一個錯誤處理提案達成共識。全部無一例外都被拒絕了。
• Google Go 團隊的資深成員們，也沒有達成最佳的前進共識。（沒有強而有力的共識）

說白了。就是搞不定。沒有最佳的錯誤處理方式。且消耗了太大的精力和時間，官方團隊自己也沒有達成共識。

圖片

在 2025 年 6 月做出了最終的決定：“在可預見的將來，Go 語言團隊將停止針對錯誤處理的語法修改。我們還將關閉所有主要涉及錯誤處理語法的開放式提案和新提案，不再進行進一步調查。”

總結

實際上 Go 這一門編程語言的 Go 錯誤處理機制，一直處于用戶調查中的風頭浪尖。但是會在互聯網上發聲的僅僅是一部分人。

但在現實和其他沒發聲的人里，也有很多支持 Go 不需要改變語法，直接還是用現在的 if err != nil 。也是存在非常多的支持者。（這一點官方在 Google Cloud Next 2025 做了個小型聚會進行了相關討論）

從現實來講，Go 核心團隊感覺非常想找到一個完美的錯誤處理機制，但現階段來看，正因為想一碗水都端平。似乎都無法解決?？赡苓€是需要當年 rsc 力推 go module 時的決心。

但很可惜，現在和社區最為親近的 ian 也已經離職了，一時半會肯定不會有所改善的了。

參考資料

[1] [ On | No ] syntactic support for error handling: https://go.dev/blog/error-syntax

[2] Error Handling — Draft Design: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md

[3] Proposal: A built-in Go error check function, try: https://go.googlesource.com/proposal/+/master/design/32437-try-builtin.md

[4] proposal: spec: reduce error handling boilerplate using ?: https://github.com/golang/go/issues/71203