在编程圈子里，关于Go语言的错误处理的抱怨声音总是不绝于耳。这些抱怨往往不是对错误处理应该如何改进的建议，而是对于频繁出现的if err != nil表示不满，认为它使代码变得冗长，并怀念像Python或JavaScript这样的动态语言中连续编写多行重要代码的便捷。
少数人会对Go缺乏类似Rust中的Result类型表示遗憾，这种类型可以包含值或错误。偶尔也会有人对高并发Go程序中的错误处理方式，或者某些错误同时是nil和非nil的情况表示不满。
我有一个大胆的观点：Go的错误处理不仅仅是好，而且对于99%的程序来说，实际上是完美的。我承认关于错误nilness的问题确实令人烦恼，但在我近十年的Go编程经历中，这种情况几乎从未出现过。
在Go中，你是否想知道程序中可能发生的坏事？即使你不知道文件读取或网络请求可能会失败，阅读Go代码后你也会明白这两者都是可能的，但从Python代码中则不会得到这样的信息。
我更愿意在代码中看到无数个if err != nil，也不愿因为错误带来的无关噪音而无法快速有效地诊断问题。
有人建议Go语言引入类似Rust中的Result类型，这种类型允许你返回一个可以包含预期值或错误的单一值。Go现在已经支持泛型，也有库实现了这一功能，但如果要在标准库中使用它，就必须打破向后兼容性，或者为现有的API调用编写Result变体，或者发布现有包的新版本，这将导致一些库和程序使用旧风格，一些使用新风格，许多程序员会因此感到困惑。
我认为，这并不会显著提高可读性。比较上面的Rust代码和Go的等效代码，我们的main函数是6行，而Rust的是4行。虽然随着时间的推移和项目的扩大，这种差异可能会累积起来，但我仍然不认为这对可读性是一个巨大的胜利。
这篇文章并不是要贬低Python、Rust、JavaScript或任何其他语言，或它们的粉丝，或者任何事物。我只是认为围绕Go编程语言的这个特定元素的许多批评忽视了大局。
#Go语言# #错误处理# #编程实践# #代码可读性# #语言比较#