大家好，我是炸鱼。每次我写一篇Go错误处理相关的提案，大家都会在评论区讨论一件事情。去也活不了。人们经常开玩笑说大型Go项目中60%的代码都是iferr!=nil。为什么我们不学习Rust的错误处理，以及整个问号的语法特点，这样就可以简化这三行，不是很好吗？从Rust借用?！|的核心点symbol就是在现有的Go例子中，我们一般都要写iferr!=nil，如果太多的话，看起来复杂麻烦。像这样编写代码：count,err=fd.Write(bytes)iferr!=nil{returnnil,err}如果我们也借鉴Rust并使用!和？简化版，我们可以演化成如下代码：count:=fd.Write!(bytes)count:=fd.Write(bytes)!count:=fd.Write(bytes)?有大佬提到我们可以进化使用||变成：fd.Write(bytes)||expr不管怎样，不用写三行iferr!=nil来处理这个硬逻辑，只需要加一个符号（类似语法糖），由编译器和运行时自己完成.此类提议将被拒绝。为什么Go最终没有落地？一般社区参与讨论的大佬认为，新的语法糖相比iferr!=nil，会增加识别和理解代码的开销，降低代码的可读性。这些神奇的功能和符号是隐藏的，更容易被人遗漏，从而引起程序控制流逻辑的变化。Go初学者也需要掌握这些符号的理解和应用，有新的学习成本。这样的提议将被彻底拒绝，停止幻想。希望开发者可以定义自己的模板。如果只是为了解决3行代码，有大佬表示Go开发者应该定义自己的错误模板。而不是引入更多的新语法来解决，这也不符合Go语言“lessismore”的定义。从Go错误处理的多个提案讨论和社区交流来看，Go在这方面似乎陷入了僵局，很像我们在极限工作中经常提到的。最重要的是投资回报率不够高。让Rust特性离开Rust。综上所述，Go错误处理iferr!=nil的解决方案成了烫手山芋，怎么改都不顺眼。以之前依赖管理的经验，我猜测最终大概率是Go团队的负责人RussCox能够搞定，否则谁都难以力挽狂澜。错误处理的碰撞是Go的真正敌人。文章持续更新中。可以微信搜索【脑补炸鱼】阅读。本文已收录在GitHubgithub.com/eddycjy/blog中。学习Go语言可以看Go学习地图和路线。欢迎星星提醒。Go书系列Go语言入门系列：初探Go项目实战Go语言编程之旅：深入使用Go做项目Go语言设计哲学：理解Go的Why与设计思维Go语言进阶之旅：进一步深入-深度围棋源码推荐阅读增加实力！Go将增强Go1的向后兼容性。兄弟们，Go1.20竞技场来了！Go十年，终于想起统一日志库！
