Pasted image 20250605093005

Go 官方再谈错误处理：新语法为何迟迟无法落地？

近日，Go 官方博客发布了一篇名为《On | No syntactic support for error handling》的文章。这篇文章没有带来期待中的语法突破，反而再次回顾了 Go 语言过去在错误处理语法上多次尝试的失败经验。
Go 团队为什么发表这么一篇文章？

为什么 Go 团队反复探讨“错误处理”？

自诞生以来，Go 语言以简洁明了著称，但却始终背负着一个无法回避的问题：错误处理语法过于冗长。
我们熟悉的 Go 错误处理通常长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


```Go
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
}

反复出现的 if err != nil 显得单调乏味，代码中大量的错误处理重复模式经常被批评为“机械且冗余”。因此，过去数年，Go 团队多次尝试设计更为简洁的新语法，但最终都未能成功落地。

曾经尝试却未成功的那些提案

Go 团队在过去提出了几种备受关注但最终放弃的方案：

2018年：check 与 handle 提案
- 尝试用新关键字简化错误传播，但社区担忧复杂度增加，被否决。
2019年：try 提案
- 引入内置函数 try，期望简化语法。但社区认为该方案过于隐式，破坏了代码的明确性，也被搁置。
2024 年：？
Ian Lance Taylor 参考 Rust 的实现提出了 “使用 ? ”减少错误处理样板也遭遇到了大量的反对意见，我也水了一篇博客

这些尝试的失败不仅仅是技术上的，更体现了 Go 社区一种特殊的文化和理念——明确胜于隐式。

真正的动机是什么？

细读这篇博客，我们会发现 Go 团队并不是单纯地“回忆过去”，而是在认真回应社区持续发酵的讨论：

究竟有没有必要为错误处理引入新语法？

文章的字里行间传递了一个关键的讯号：

“Go 社区对于新语法的需求，并非简单的‘yes or no’，而是深入涉及到语言设计哲学和社区价值观的问题。”

换句话说，Go 团队的动机并不是要立即给出一个新提案，而是希望借此引导社区回到初心，认真审视“我们真正需要什么样的语言设计？”

“明确胜于隐式”：Go 社区无法放弃的原则

Go 语言的成功，正是因为其清晰且明确的设计哲学。任何新语法都必须经过社区的严格审视：

新语法能否保持明确性？
新语法能否带来足够的收益，值得牺牲现有的简单性？
新语法是否有可能带来其他负面影响？
在这种原则下，每个提案都难免面临严格审视和质疑。这也是过去的尝试频频受挫的根本原因。

五、未来的路在哪里？

这篇官方博客所释放的另一个信息是：

Go 团队已经接受了短期内不会推出新错误处理语法的现实。

他们似乎在暗示：错误处理的语法简化并非完全不可行，但至少现在还未找到完美的答案，社区需要更多时间的探索、实践与反思。
因此，未来很长一段时间内，Go 程序员仍需忍受现有模式的重复。但同时也意味着，Go 语言暂时保持了它清晰、直接、没有魔法的风格。

Go 团队主动发布这样一篇文章，看似回顾历史、承认失败，实则希望引发社区更深层次的讨论：

我们究竟希望 Go 变成什么样子？
为了简洁，我们愿意牺牲多少明确性？

无论你是否赞同当前的处理方式，这样的反思和讨论对于语言生态的健康发展，都是极其重要的。
也许下一次提案会再次失败，也许未来某一天，社区终究找到满意的平衡点。但至少，我们可以肯定的是：
Go 社区一直在探索，一直在反思，也一直在进步。
原文链接：https://go.dev/blog/error-syntax

本文长期链接
如果您觉得我的博客对你有帮助，请通过 RSS订阅我。
或者在X上关注我。
如果您有Medium账号，能给我个关注嘛？我的文章第一时间都会发布在Medium。