Go 错误处理语法之争尘埃落定？Go 团队为何十五年探索后仍选择“不”-CSDN博客

本文链接：https://blog.csdn.net/bigwhite20xx/article/details/148461784

请点击上方蓝字TonyBai订阅公众号！

大家好，我是Tony Bai。

长久以来，Go 语言中 if err != nil 的错误处理模式因其普遍性和由此带来的代码冗余，一直是社区反馈中最持久、最突出的痛点之一。尽管 Go 团队及社区投入了大量精力，历经近十五年的探索，提出了包括 check/handle、try 内建函数以及借鉴 Rust的?操作符在内的多种方案，但始终未能就新的错误处理语法达成广泛共识。近日，Go 官方团队通过一篇博文（https://go.dev/blog/error-syntax）正式阐述了其最新立场：在可预见的未来，将停止寻求通过改变语法来简化错误处理，并将关闭所有相关的提案。 这一决策无疑在 Go 社区引发了广泛关注和深入思考。

漫漫探索路：从 `check/handle` 到 `?` 操作符

Go 语言的错误处理冗余问题，尤其在涉及大量 API 调用且错误处理逻辑相对简单的场景下尤为突出。一个典型的例子如下：

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
}

在这个函数中，近一半的代码行用于错误检查和返回，这无疑增加了代码的视觉噪音，降低了核心逻辑的清晰度。因此，多年来，改进错误处理的呼声在 Go 开发者年度调查中一直居高不下。

Go 团队对此高度重视，并进行了一系列尝试：

`check/handle` 机制 (2018年)

由 Russ Cox 正式提出，基于 Marcel van Lohuizen 的草案设计。该机制引入了 check 用于检查错误并提前返回，handle 用于定义错误处理逻辑。

// 设想的 check/handle 用法
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
}

然而，该方案因其复杂性未被广泛接受。

`try` 内建函数 (2019年)

作为 check/handle 的简化版，try 函数会在遇到错误时从其所在的封闭函数返回。

// 设想的 try 用法
func printSum(a, b string) error {
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x + y)
    return nil
}

尽管 Go 团队投入巨大，但 try 因其隐式的控制流改变（可能从深层嵌套表达式中返回）而遭到许多开发者的反对，最终也被放弃。Go 团队反思，或许引入新关键字并限制 try 的使用范围会是更好的路径。

借鉴 Rust 的 `?` 操作符 (2024年)

由 Ian Lance Taylor 提出，希望通过借鉴其他语言中已验证的机制来取得突破。

// 设想的 ? 操作符用法
func printSum(a, b string) error {
    x := strconv.Atoi(a) ?
    y := strconv.Atoi(b) ?
    fmt.Println("result:", x + y)
    return nil
}

此方案虽然在小范围用户研究中表现出一定的直观性，但在社区讨论中依然未能形成足够支持，并引发了大量关于细节调整的建议。

除了官方提案，社区也贡献了数以百计的错误处理改进方案，但无一例外都未能获得压倒性的支持。

官方立场：为何按下暂停键？

面对多年探索未果的局面，Go 团队基于以下几点理由，做出了暂停错误处理语法层面改进的决定。

缺乏社区共识

这是最核心的原因。根据 Go 的提案流程，一项提案需要得到社区的普遍共识才能被接受。然而，在错误处理语法这个问题上，无论是官方还是社区的提案，都未能凝聚起足够的共识。甚至 Go 团队内部也未能就最佳方案达成一致。

维护现状的合理性

时机问题: Go 已经发展了十五年，现有的错误处理方式虽然冗余，但功能完善且被广泛理解和使用。早期引入语法糖可能更容易被接受，但现在改变的门槛更高。
避免制造新的“不快乐”: 即使找到了“完美”方案，强制推广新语法也可能让习惯了现有方式的开发者感到不适，重蹈类似泛型引入初期的一些争议。但与泛型不同，错误处理语法几乎会影响所有开发者。
Go 的设计哲学: Go 倾向于“只提供一种（或尽可能少）的方式来做同一件事”。引入新的错误处理语法会打破这一原则。有趣的是，:= 短变量声明中的变量重声明规则，最初也是为了解决连续错误检查中 err 变量命名问题而引入的，如果早期有更好的错误处理语法，这个规则或许就不需要了。

关注错误处理的本质，而非仅仅语法

当错误被“真正处理”时，冗余感会降低。 良好的错误处理通常需要附加额外上下文信息，而不仅仅是简单返回。例如：

func printSum(a, b string) error {
    x, err := strconv.Atoi(a)
    if err != nil {
        return fmt.Errorf("invalid integer: %q", a) // 附加信息
    }
    // ...
    return nil
}

在这种情况下，if err != nil 的样板代码占比相对减小。

标准库的增强： 新的库函数（如 cmp.Or）或未来的库特性，可以在不改变语法的情况下帮助减少错误处理的样板代码。

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

工具的辅助作用

编写时： 现代 IDE（包括基于 LLM 的工具）已经能够很好地辅助生成重复的错误检查代码。
阅读时： IDE 或可提供隐藏/折叠错误处理代码块的功能，减少视觉干扰。
调试时： 显式的 if 语句更便于设置断点和添加调试输出，而高度集成的语法糖可能会使调试变得复杂。

语言演进的成本与优先级

任何语言的改动都伴随着巨大的成本：设计、实现、文档更新、工具调整以及社区的适应。Go 团队规模有限，需要优先处理其他重要事项。
开发者习惯的演变： 许多有经验的 Go 开发者表示，随着对 Go 错误处理哲学的深入理解和实践，最初感到的冗余问题会逐渐减轻。

对开发者的影响与未来展望

Go 团队的这一决定，意味着在可预见的未来，if err != nil 仍将是 Go 语言错误处理的标准范式。开发者需要：

接受现状并深入理解其哲学： Rob Pike 的名言“Errors are values”依然是理解 Go 错误处理的核心。错误是程序正常流程的一部分，显式处理它们有助于编写健壮的软件。
利用现有工具和库：
- 善用 IDE 的代码生成和辅助功能。
- 探索和使用标准库或第三方库提供的错误处理辅助工具（如 errors.Is, errors.As, fmt.Errorf的 %w 以及可能的新库特性）。
关注代码质量而非单纯追求简洁： 在需要详细错误上下文的地方，不要吝啬代码。清晰、可追溯的错误比极度简化的语法糖更有价值。
代码可读性依然重要： 尽管语法层面不再追求极致简洁，但在错误处理逻辑本身，依然要力求清晰、易懂。