Go 为什么不像 Rust 用？！做错误处理？

煎鱼煎鱼 - 2023-03-17 00:15:26

大家好，我是煎鱼。

之前每次写 Go 错误处理的相关提案时，大家都会在评论区探讨到一个事。

Go 这活不得劲，常被戏称，一个大型 Go 工程项目里 60% 的代码都是 if err != nil。

咱们错误处理怎么不借鉴一下 Rust，高低也整个问号的语法特性，就可以简化这三行了，不香吗？

借鉴 Rust 用？！| 符号

核心的点是在现有的 Go 例子中，我们一般要写 if err != nil，多了之后又多又杂看起来还有些麻烦。

如下 Go 代码：

count, err = fd.Write(bytes)
if err != nil {
    return nil, err
}

如果我们也借鉴 Rust 使用 ! 和？的简化版，我们可以演进为如下代码：

count := fd.Write!(bytes)

count := fd.Write(bytes)!

count := fd.Write(bytes)?

也有大佬提到可以演进一下使用 || 变成：

fd.Write(bytes) || Expr

不管如何，就是不需要写三行的 if err != nil 去处理这个硬逻辑，只要加个符号（类似语法糖）就行，由编译器和运行时自己去处理就完了。

这类提案都会被拒绝

为什么最后 Go 没有落地呢？

普遍社区中参与讨论的大佬认为，新的语法糖相较 if err != nil，会增加认知和理解代码的开销，并降低代码可读性。

这些神奇的的功能和符号，他们是隐秘的，更容易让人错过，会导致程序控制流逻辑发生改变。

Go 初学者也需要额外掌握这几个符号的理解和应用，有新的学习成本。

这类提案会被直接拒绝，不要再幻想了。

希望开发者自己定模板

如果只是为了解决那 3 行代码，部分大佬表示 Go 开发者应该自己定义错误模板。

而不是借助引入更多的新语法来解决，这也不符合 Go 语言对 “less is more” 的理念定义。

从现在对 Go 错误处理的多个提案讨论和社区交流来看，Go 在这块似乎已经陷入僵局，很像我们极限工作中常提的既要也要还要，重要的是 ROI 也不够高。

让 Rust 特性留给 Rust。

总结

Go 错误处理 if err != nil 的解决，已经成为了一块烫手的山芋，怎么改都不讨好了，相关负责人积极讨论，实施持续摆烂中。

根据以往在依赖管理的，我猜测最终大概率会由 Go 团队大当家 Russ Cox 操刀，否则很难有人能力挽狂澜。

错误处理的碰撞，真是 Go 的一生之敌。

文章持续更新，可以微信搜【脑子进煎鱼了】阅读，本文 GitHub github.com/eddycjy/blog 已收录，学习 Go 语言可以看 Go 学习地图和路线，欢迎 Star 催更。Go 图书系列Go 语言入门系列：初探 Go 项目实战Go 语言编程之旅：深入用 Go 做项目Go 语言设计哲学：了解 Go 的为什么和设计思考Go 语言进阶之旅：进一步深入 Go 源码推荐阅读加大力度！Go 将会增强 Go1 向后兼容性打脸了兄弟们，Go1.20 arena 来了！Go 十年了，终于想起要统一 log 库了！

特别申明：本文内容来源网络，版权归原作者所有，如有侵权请立即与我们联系（cy198701067573@163.com），我们将及时处理。