之前每次写 Go 错误处理的相关提案时,大家都会在评论区探讨到一个事。
Go 这活不得劲,常被戏称,一个大型 Go 工程项目里 60% 的代码都是 if err != nil。
咱们错误处理怎么不借鉴一下 Rust,高低也整个问号的语法特性,就可以简化这三行了,不香吗?
借鉴 Rust 用 ?!| 符号
核心的点是在现有的 Go 例子中,我们一般要写 if err != nil,多了之后又多又杂看起来还有些麻烦。
如下 Go 代码:
如果我们也借鉴 Rust 使用 ! 和 ?的简化版,我们可以演进为如下代码:
也有大佬提到可以演进一下使用 || 变成:
不管如何,就是不需要写三行的 if err != nil 去处理这个硬逻辑,只要加个符号(类似语法糖)就行,由编译器和运行时自己去处理就完了。
这类提案都会被拒绝
为什么最后 Go 没有落地呢?
普遍社区中参与讨论的大佬认为,新的语法糖相较 if err != nil,会增加认知和理解代码的开销,并降低代码可读性。
这些神奇的的功能和符号,他们是隐秘的,更容易让人错过,会导致程序控制流逻辑发生改变,增加程序员的心智负担。
Go 初学者也需要额外掌握这几个符号的理解和应用,有新的学习成本。
这类提案会被直接拒绝,请大家不要再幻想了。
希望开发者自己定模板
如果只是为了解决那 3 行代码,部分大佬表示 Go 开发者应该自己定义错误模板。而不是借助引入更多的新语法来解决,这也不符合 Go 语言对 “less is more” 的理念定义。
从现在对 Go 错误处理的多个提案讨论和社区交流来看,Go 在这块已经陷入僵局,很像工作中的什么呢?
像我们常提的既要也要还要,重要的是这事 ROI 也不够高,导致Go 核心团队的动力不足,也不想互相得罪了。
只能甩出一句经典:”让 Rust 特性留给 Rust“。
总结
Go 错误处理 if err != nil 的解决,已经成为了一块烫手的山芋,怎么改都不讨好了,相关负责人积极讨论,实施持续摆烂中,没有新的建设。
根据以往在依赖管理的,我猜测最终大概率会由 Go 团队大当家 Russ Cox 操刀,否则很难有人能力挽狂澜。不过,目前来看他对此并不感兴趣。对于开启 Go 工具链遥测的提案,也刚吃了闭门羹。
错误处理的碰撞,真是 Go 的一生之敌。