Go 为什么不像 Rust 用 ?!做错误处理?

开发 项目管理
Go 错误处理 if err != nil 的解决,已经成为了一块烫手的山芋,怎么改都不讨好了,相关负责人积极讨论,实施持续摆烂中,没有新的建设。

大家好,我是煎鱼。

之前每次写 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 也不够高,导致Go 核心团队的动力不足,也不想互相得罪了。

只能甩出一句经典:”​让 Rust 特性留给 Rust“。

总结

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

根据以往在依赖管理的,我猜测最终大概率会由 Go 团队大当家 Russ Cox 操刀,否则很难有人能力挽狂澜。不过,目前来看他对此并不感兴趣。对于开启 Go 工具链遥测的提案,也刚吃了闭门羹。

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

责任编辑:武晓燕 来源: 脑子进煎鱼了
相关推荐

2022-12-12 08:53:53

Go版本方式

2021-04-29 09:02:44

语言Go 处理

2014-11-17 10:05:12

Go语言

2020-12-17 06:25:05

Gopanic 模式

2024-02-28 08:54:57

switchGo错误

2022-06-26 23:03:14

Go标准库语言

2022-05-26 08:53:47

Go函数代码

2024-03-14 09:35:54

Go 错误select代码

2022-09-05 08:55:15

Go2提案语法

2021-09-13 07:53:31

Go错误处理

2021-09-27 10:04:03

Go程序处理

2023-10-26 15:49:53

Go日志

2021-09-27 15:33:48

Go 开发技术

2021-09-27 23:28:29

Go多协程并发

2022-08-01 08:48:39

Go代码接口

2022-07-13 08:53:28

函数Go语言

2021-04-14 07:08:14

Nodejs错误处理

2015-11-17 10:00:50

DGORust

2015-11-17 08:54:42

语言gorust

2022-10-24 08:55:13

Go工具链开发者
点赞
收藏

51CTO技术栈公众号