这是一个创建于 128 天前的主题，其中的信息可能已经有所发展或是发生改变。
官方 blog 在这里 https://go.dev/blog/error-syntax
原文本身不是太长，主要说了几种曾经考虑的方案。具体方案讨论链接里的内容就很多了。
最终决定不改了的主要理由是没有形成共识，次要理由是这事不太重要。
 | 1 rmrf 128 天前 挺好的，不折腾了 |
 | 2 momowei 128 天前 没有特别好的方案吧 ，哪种方案都有反对的，现在的就是裹脚布，但没啥问题，有 ai 就更不是问题了 |
 | 3 RedisMasterNode 128 天前  16 明明强制做错误判断才是最好的姿势，还好没改) |
 | 4 nativeBoy 128 天前 via Android vscode 有个插件可以把错误处理代码变得透明，这有利于浏览代码，没那么杂乱 |
 | 5 lloovve 128 天前 via iPhone 我觉得挺好 |
 | 6 coyove 128 天前 官方做人，终于干了件正事 |
 | 7 WaterWestBolus 128 天前 @nativeBoy 请问名字是？ |
 | 8 wfhtqp 128 天前 挺好的 |
 | 9 Akitora 128 天前 我明明觉得 ? 这个方案挺好的…… |
 | 11 xfriday 128 天前 @RedisMasterNode a, _ := foo() 怎么强制？又不是 Rust 可以返回 enum ，必须要判断 |
 | 12 Lightbright 128 天前 @deacyn #10 lowlight go errors |
 | 13 Razio 128 天前 不改挺好的，error 强迫症福利。反正改不改，怎么改都会被反对，浪费精力，没意义 |
 | 14 xuhuanzy 128 天前 via Android 这种具有争议的问题要投票改等于不改，假惺惺的开个讨论装装样子 |
 | 15 tongbufu 128 天前 via iPhone 这是好事儿啊 |
 | 16 dacapoday 128 天前 本来就不需要改，尤其现在 AI 能帮着写。 |
 | 17 bronyakaka 128 天前 10 if err != nil 是 go 粉应得的  |
 | 18 Lockroach 128 天前 不改以后就能有一个新语言可以打着 go 后继者的名声出来，想好了，就叫下一代的后端语言，摒弃 if .. != nil ，性能更高等等特性 |
 | 19 XIVN1987 128 天前 挺好，，没有共识就暂时保持现状，，等有绝大多数人都满意的方案了再改。。 |
 | 20 Felldeadbird 128 天前 error 处理我觉得挺好的，都明确错误。嗦是嗦，安全是安全。 |
 | 21 rozbo 128 天前 众口难调啊，但是 ? 这个还有人反对的话，确实没必要进行下去了。。。 |
 | 22 noyidoit 128 天前 挺好的，以后都不用想着这件事了。个人觉得不管是读还是写`if err!=nil`都没什么代价，改掉它的收益大概只会随着 AI 普及越来越低 |
23 fioncat 128 天前 个人觉得 ? 是最接近的。但是很多人觉得隐晦。 可能是用户习惯问题，Rust 那边 ? 满天飞好像抱怨的人不多 |
 | 24 duzhuo 128 天前 @bronyakaka 已经是语言特色了，不写 golang 的人都知道这个 |
 | 25 littlewing 128 天前 1 不理解这种错误处理方式有啥问题吗？写 C/C++ 都是通过返回值来表示是否成功的，虽然 C++ 有异常处理机制，但是几乎不用 |
 | 26 xjzshttps 128 天前 由 ide 的情况下 if err 真没什么大问题。 写的时候 goland 自动写，看的时候 ide 会折行。 |
 | 27 kfpenn 128 天前 不改挺好的 |
 | 28 henix 128 天前 个人认为 Go 没有 C 那种宏挺遗憾的，有的话一个宏就搞定了，但现在这样也问题不大，反正已经写了这么多年了 |
 | 29 Yadomin 128 天前 1 说的他们好像多在乎用户意见一样，达不成共识就不改了，那怎么泛型写的一坨屎还能上呢？说白了 golang 就是 sb Google 的一言堂罢了。 |
 | 30 liuguang 127 前 1 go 语言最 sb 的一点是每一层都要来一个 if err!=nil |
 | 31 mightofcode 127 天前 躺平了 |
 | 32 guidao 127 天前 挺好的。KISS |
 | 33 Steaven 127 天前 要是有一个组合的语法就好，像 erlang 这样 https://www.erlang.org/blog/my-otp-25-highlights/#motivation |
 | 34 baseline 127 天前 挺好的，kpi 爽到爆。 |
 | 35 ShaunSS 127 天前 喜大普奔 |
 | 37 janyork 127 天前 挺好的 |
 | 38 1 设想下平行世界中加了新的错误处理的 Google 会怎么说。 我们尊重开发者意见，为 go 增加了新的错误处理机制，让这个已经有 10 多年历史的语言重新焕发生机，我们知道可能会有很长时间转型的“阵痛期”，但是这一切都是为了更好的 go 语言进行服务。 过去的几年中 go 语言的变化很大，经历了泛型，range over func 等重大特性，并且这次引入的全新错误处理，我们相信 go 语言可以持续的焕发生机，迎接新时代的挑战。 我们是持续拥抱变化，尊重开发者的 go 团队（狗头 |
 | 39 razeen 127 天前 挺好，有了 AI ，写完 `err :=` `if err != nil` 就自动补全了  |
 | 40 levelworm 127 天前 via Android 除非是严重的错误，否则不折腾是最好的。我高看他一眼。 |
 | 41 chachi 127 天前 让我想起了 vb 的 on error resume next 和 if err.number<>0 then |
 | 42 Crawping 127 天前 还好没改.. AI 纪元下 无非就是按一下 Tab 的事儿啊, 目前虽然嗦 但是并没有任何心智负担,纯纯流水账. 简单清晰, 非要省那么点不要钱的行数 把代码弄的晦涩么.. (本人主要写 C++ 十几年了从不用 try catch 1:容易渗漏传染 2:第一现场不明确) |
 | 43 agagega 127 天前 上面提到 C++的，C++类型系统足够强大，使用类似 Rust 的 ADT 机制处理错误完全不是问题，甚至 optional 和 expected 已经是标准一部分了 |
 | 45 KellaTeRyan 127 天前 @razeen 就属你的头像最亮眼。 |
 | 49 htxy1985 127 天前 不懂就问，39 楼的头像怎么了，我没看到有什么不同啊 |
 | 50 zpvip 127 天前 现在有 AI 了, Javascript 我都用 AI 给我的 vanilla-js, bugfix 也是自己做, 大部分情况下根本不看代码. 以后 AI 就直接写二进制了, 人类不用参与, 显得多余. |
 | 51 rainfd 127 天前 反正我写没觉得有多大问题，大家意见都不统一，干脆别改 |
| 53 nativeBoy 127 天前 via Android |
 | 54 akiyamamio 127 天前 直接 panic 处理！ |
 | 56 Pencillll 126 天前 via Android 看了一下列出的几点理由，差不多就是"我们本可以做点什么，但现在已经晚了" |
 | 57 realpg PRO @littlewing #25 JAVA 人总是希望谁都改成他们最习惯的样子 |
 | 58 loading 126 天前 1 按 fmt 这种强制的思路，不改才是语言特色。 当时我想，如果它改了，我就不用 GO 了。 |
 | 60 joeycheek 126 天前 都习惯了，不改也好 |
 | 61 yijiangchengming 125 天前 我已经习惯了 GO 的错误处理，它能减少意外的错误。即使明确不需要错误处理，此处不可能发生错误，使用_即可规避。 |
 | 62 Miranquil 125 天前 via iPhone @Felldeadbird 现在的处理可和安全一个字都不沾边 |
 | 64 codefun666 125 天前 Go 的错误处理显然借鉴了内核的错处处理方式，习惯就好了，没毛病。 |
 | 65 ranran 125 天前 VB 的异常处理也很烦，不过习惯就好了 |
 | 66 guzzhao 124 天前 能多加一些 error 的工具类也不错 |
 | 68 bunny189 123 天前 via iPhone 我觉得 if err != nil 挺好的，写多了还……还挺爽的 |
Select Language