Go 错误处理：100+ 提案全部被拒绝，为何现阶段仍用 if err != nil？

大家好，我是煎鱼。

这些年给 Go 提新的错误处理提案的人络绎不绝，挡都挡不住。Ian Lance Taylor 作为历史的亲历者之一特意梳理了《language: Go 2: error handling meta issue》。

今天结合我自己写过的内容分享给大家，以后有人再问可以甩给他们，这样他就懂前因后果了。

背景

在 2018 年 8 月，现任 Go 核心团队负责人 Russ Cox 给 Go2 的错误处理画了一个大大的蓝图，并介绍了一个未实现的设计草案。

具体目标如下：

在此之后，也由于 Go 的热浪，许多新的提案作为 Go2 的错误处理变更提交，Go 邮件也有大量的讨论，拥有许多尝试，但迄今为止没有一个被接受。

这就是现在 Go 错误处理的背景。

当然，这个合集并不 100% 全面，如果需要全查看一遍，可以自行在 go/issues 库搜索 error-handling 标签就可以了。

以下是一些值得关注的错误处理提案合集：

Go2 check/handle 方法：
- 主要原因之一：handle 和 defer 之间缺乏清晰度。
- 关联文章：先睹为快，Go2 Error 的挣扎之路
常被提起的 try-catch 方法：
- 主要原因：额外的流程控制，使用 try 的复杂表达式可能导致函数返回。 Go 目前在表达式级别没有控制流结构（panic 除外），会引入额外设计。
- 关联文章：Go try 新提案靠谱吗？想简化错误处理了
像 Rust 用 ! ? 作为错误检查：
- 主要原因：! ? 都比较的隐晦，会导致心智负担加大，会导致控制流发生变化。
- 关联文章：Go 为什么不像 Rust 用？！做错误处理？
简化 if err != nil {} 减少代码量：
- 主要原因：只是为了代码量，就因此导致变更语言；同时也会导致复杂性加大，因为通常都比较的隐晦。这类提案通常都会被拒绝。
- 关联文章：Go 只会 if err != nil？这是不对的，分享这些优雅的处理姿势给你！
使用左侧函数和表达式来替代：
- 主要原因：Go 设计哲学上不建议这种做法，与常见的阅读代码习惯会有些相悖，降低了代码可读性。
- 关联文章：Go 错误处理新思路？用左侧函数和表达式

常见的基本是这几类，有许多雷同的，或被拒绝原因类似的提案，在社区管理上最终都会被指向到一起并关闭。

你可以通过上述提案的前因后果，可以看到 Go 核心团队的一些衡量标杆。基本就是：显式、简洁、省心、好用。

Go 的 “新” 错误处理已经经历了 3，5 年了，许多社区友人已经想了许多许多，也提出了许多提案。在 error-handling 标签下共有 100+ 个提案，无一幸免，全部被拒绝。

现阶段还是好好的用 if err != nil，也是许多人认可的。或是自己团队内封装一套共识标准，也是可以的。

让风再吹一会。

文章持续更新，可以微信搜【脑子进煎鱼了】阅读，本文 GitHub github.com/eddycjy/blog 已收录，学习 Go 语言可以看 Go 学习地图和路线，欢迎 Star 催更。