大家好，我是煎鱼。
这些年给 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 之间缺乏清晰度。
- 关联文章：
- 常被提起的 try-catch 方法：
- 主要原因：额外的流程控制，使用 try 的复杂表达式可能导致函数返回。 Go 目前在表达式级别没有控制流结构（panic 除外），会引入额外设计。
- 关联文章：
- 像 Rust 用 ! ? 作为错误检查：
- 主要原因：! ? 都比较的隐晦，会导致心智负担加大，会导致控制流发生变化。
- 关联文章：
- 简化 if err != nil {} 减少代码量：
- 主要原因：只是为了代码量，就因此导致变更语言；同时也会导致复杂性加大，因为通常都比较的隐晦。这类提案通常都会被拒绝。
- 关联文章：
- 使用左侧函数和表达式来替代：
- 主要原因：Go 设计哲学上不建议这种做法，与常见的阅读代码习惯会有些相悖，降低了代码可读性。
- 关联文章：
常见的基本是这几类，有许多雷同的，或被拒绝原因类似的提案，在社区管理上最终都会被指向到一起并关闭。
你可以通过上述提案的前因后果，可以看到 Go 核心团队的一些衡量标杆。基本就是：显式、简洁、省心、好用。
总结
Go 的 “新” 错误处理已经经历了 3，5 年了，许多社区友人已经想了许多许多，也提出了许多提案。在 error-handling 标签下共有 100+ 个提案，无一幸免，全部被拒绝。
现阶段还是好好的用 if err != nil，也是许多人认可的。或是自己团队内封装一套共识标准，也是可以的。
让风再吹一会。
Go 图书系列
推荐阅读
参考资料
[1]
language: Go 2: error handling meta issue: