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

大家好，我是煎鱼。

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

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

背景

在 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，也是许多人认可的。或是自己团队内封装一套共识标准，也是可以的。

让风再吹一会。

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

Go 图书系列

• Go 语言入门系列：初探 Go 项目实战
• Go 语言编程之旅：深入用 Go 做项目
• Go 语言设计哲学：了解 Go 的为什么和设计思考
• Go 语言进阶之旅：进一步深入 Go 源码

推荐阅读

• Go1.20 arena 能手动管理内存了，怎么用？
• Go 在信创这一块会输给 Java，想不通。。。
• 写在 2023 年初的后端社招面试经历（四年经验）：字节 米哈游 富途 猿辅导