Go 社区否决了新的 try 语句提议

[SsuchingYu]

Proposal: A built-in Go error check function, "try" · Issue #32437 · golang/go https://github.com/golang/go/issues/32437

[SsuchingYu]

[jinliming2]

我也觉得，如果单纯是语法糖的话，旧语法和新语法间可以完全相互转换的话，没有必要。

[rrfeng]

刚好前几天看了眼，感觉 try 根本就没解决问题，只是看起来 /写起来稍微简单了点，所以被拒是正常的。

[kidlj]

其实 try() 不是真正的 error _handling_，只是检查 err != nil 并直接返回，Griesemer 的 tryhard 工具也验证了在现有代码库里能应用到的地方很有限，为了这一点点便利而引入一种新的写法不值得。

我认为当前 if err != nil 的模式肯定有可以改进的地方，但肯定不是 try()，所以很高兴这个提案被撤回了。

[dbskcnc]

这个好, 虽然 if err!=nil 是有点啰嗦,但是对于程序稳定性真的非常好

[flowfire]

@jinliming2 #2
@rrfeng #3

语法糖为什么没有必要。。。
async await 就是 Promise+Generator 的语法糖啊。。。
能节省开发效率当然是好事。。。

[janxin]

否决不是坏事，起码社区力量的展示吧。

[Hellert]

要解决就一次性永久解决，别搞什么中间方案，支持否决。

[ruyuejun]

非常 nice。
没有对写法造成根本性的改变的语法糖，我认为是不必要的。
相应的，js 的 async await 语法糖带来的是颠覆式的书写风格，利远大于弊，当然觉得很好，而 go 中的 try 不但没有根治异常处理，还带来了恶心的函数嵌套。
我理解的是 Go 社区不应该过分坚持简单、单一哲学，坚持没错，但是这个地方如此沉重，和泛型一样，应该有大刀阔斧的改革勇气

[boboliu]

这个 try 函数作为语法糖的意义确实很低…… go 目前的关键字和内置函数很克制，个人认为加这样一个隐藏细节且对程序稳定性没有好处的谜之语法糖并没有使 go 的 error handle 更友好的效果。

[rrfeng]

@flowfire
async await 收益巨大，傻子也能写异步了。promise 真的太难了。
try 相比之下收益太小了，错误处理还是要写，只能包一个 func （这点真的很蠢……），而且现在很多 MustFunc 写法。总之看起来就不是个好的解决方案，况且它没解决根本问题。

[janxin]

try(try(try(try(try(try(try(try(try(try(f()))))))))))

你要是敢让人这么写，就一定会有人这么写。实际上我是支持解决 error hanling 问题，但是 built-in try 函数方案，就是不行...其实我倒是觉得引入 Rust 的?可以，不过大佬们觉得麻烦不是，我觉得这个事情社区可以再推一推

[Rorysky]

@flowfire go 的事情 能和 ecmascript 一样么？

[x7395759]

支持！

[wysnylc]

@janxin #12 只存在不用和滥用,不滥用是不可能的

[qq976739120]

try 这样的语法糖,第三方实现的很多了,喜欢的早用上了,算啥改进啊

[luoyou1014]

@janxin rust 的也很麻烦的，match match match unwrap unwrap 顺带 Some 里面的内容可能是引用的，处理起来就是一个字，烦。

[ChristopherWu]

@qq976739120 go 没有宏，怎么做语法糖？包个函数做法太奇怪了。

[ChristopherWu]

@dbskcnc 跟异常比起来，哪里对稳定性好？

[petelin]

有什么好 try 的
错误都不处理 还想写出来好软件