[ On | No ] syntactic support for error handling - The Go Programming Language

URL: 原文
Added At: 2025-06-06 01:59:58
Link To Text

TL;DR

Go语言长期存在的错误处理冗长问题，经过多次提案（如check/handle、try、?）尝试均告失败。Go团队最终决定停止语法层面的改进，原因是缺乏共识、可能导致用户分歧以及设计原则的考量。未来将通过辅助函数、标准库功能、IDE工具等替代方案，并关注错误处理的可见性，同时将精力集中于Go的其他改进方向。

Summary

好的，这是对你提供的文章的详细总结：

问题提出：Go语言中错误处理的冗长性是一个长期存在的问题，大量的 if err != nil 代码块降低了代码可读性。
示例代码：
- 展示了包含大量错误检查代码的函数示例，说明了冗长性的问题。
- 指出在函数体中，实际执行功能的代码行数少于错误处理代码行数。
历史尝试：Go团队曾多次尝试解决这个问题，但都未成功。
- 2018年方案：基于check和handle机制，但被认为过于复杂。文档详细分析了其他语言的错误处理方法。
- 2019年try方案：简化了check和handle，使用内置函数try，但因影响控制流而被放弃。限制try的使用范围可能有所帮助。
- 经验教训：过早地呈现完整提案，缺少社区反馈空间，导致结果不佳。
社区参与：虽然Go团队暂停了语法更改，但社区提出了大量错误处理方案。
- Ian Lance Taylor创建了一个汇总问题，总结了改进错误处理的提案。
- Go Wiki收集了相关的反馈、讨论和文章。
- 社区成员整理了大量的错误处理提案。
最新提案(?)：2024年，Ian Lance Taylor提出了使用?运算符的方案，借鉴了Rust的实现。
- 小型用户研究表明，大多数参与者能够正确理解使用?的代码。
- 该提案也因过多建议和个人偏好而被搁置。
当前决定：Go团队决定在可预见的未来停止尝试解决语法问题。
- 原因是没有达成普遍共识，即使是Go团队内部也没有一致意见。
- 所有关于错误处理语法的提案将被关闭。
支持现状的理由：
- 历史原因：早期引入语法糖会更好，但现在已经太晚了。
- 用户分歧：即使有完美方案，也会导致用户群体的不满。
- 设计原则：避免提供多种做同一件事的方式。
- 实际应用：良好的错误处理需要添加额外信息，冗长性会降低。
替代方案与工具：
- 提供支持函数来生成包含更多信息的错误。
- 使用标准库功能（如cmp.Or）来处理一系列错误。
- IDE可以提供代码完成、隐藏错误处理代码等功能。
- 调试时，显式的if语句更易于添加断点和输出信息。
实际考虑：
- 设计和实施语言变更的成本很高。
- Go团队规模相对较小，有其他优先级更高的任务。
- 用户反馈显示，许多Go用户认为不应更改语言的错误处理方式。
支持变更的理由：
- 缺乏更好的错误处理仍然是用户调查中的首要抱怨。
- 或许应该关注错误处理的可见性，而不是减少字符数。
- 需要更深入地研究语法冗长和好的错误处理之间的关系。
未来方向：
- Go团队将停止追求错误处理的语法语言更改。
- 关闭所有关于错误处理语法的提案。
- 将精力集中在其他改进Go的机会上。