Go 错误处理：100+ 提案全部被拒绝，为何现阶段仍用 if err != nil？
大家好，我是煎鱼。
这些年给 Go 提新的错误处理提案的人络绎不绝，挡都挡不住。Ian Lance Taylor 作为历史的亲历者之一特意梳理了《language: Go 2: error handling meta issue[1]》。
今天结合我自己写过的内容分享给大家，以后有人再问可以甩给他们，这样他就懂前因后果了。
背景
在 2018 年 8 月，现任 Go 核心团队负责人 Russ Cox 给 Go2 的错误处理画了一个大大的蓝图，并介绍了一个未实现的设计草案。
具体目标如下：
期望 Go 的错误检查更轻量级，能够减少被大家吐槽的错误检查的程序文本数量。整体上要确保错误处理更加方便，复杂度不能变高。 错误检查和错误处理都必须保持显式，这意味着在 Go 程序中是可见的。我们不想重复异常处理的陷阱。 必须保证现有的 Go 代码的兼容性，不能有破坏性升级。
在此之后，也由于 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，也是许多人认可的。或是自己团队内封装一套共识标准，也是可以的。
让风再吹一会。也许不会改变了。
推荐阅读
参考资料
language: Go 2: error handling meta issue: https://github.com/golang/go/issues/40432
关注和加煎鱼微信，
一手消息和知识，拉你进技术交流群👇
你好，我是煎鱼，出版过 Go 畅销书《Go 语言编程之旅》，再到获得 GOP（Go 领域最有观点专家）荣誉，点击蓝字查看我的出书之路。
日常分享高质量文章，输出 Go 面试、工作经验、架构设计，加微信拉读者交流群，和大家交流！