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

[SsuchingYu]

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

[neoblackcap]

@xfriday rust 里面是学习 haskell 的 monad，除非你是消费以及最终求值的阶段，否则不会有人会去用 match 来处理错误。
rust 的错误处理最大的优势就是，之前步骤的异常，并不会影响你的业务逻辑，以及强制错误处理。你完全可以使用 and_then 或者 map 方法对一个 Result 进行结果转换，完全不用什么 match。?只是一个相对简洁的语法糖，就算不用 rust 也比现有的什么异常以及返回值优秀。
当然你不了解 monad，强制每一步都 match 一下，那就认为 rust 也是返回值吧。毕竟宝马跟单车都是靠轮子走的，而且都是圆的。

[fengjianxinghun]

@ChristopherWu


```
// Serve a new connection.
func (c *conn) serve(ctx context.Context) {
c.remoteAddr = c.rwc.RemoteAddr().String()
ctx = context.WithValue(ctx, LocalAddrContextKey, c.rwc.LocalAddr())
defer func() {
if err := recover(); err != nil && err != ErrAbortHandler {
const size = 64 << 10
buf := make([]byte, size)
buf = buf[:runtime.Stack(buf, false)]
c.server.logf("http: panic serving %v: %v\n%s", c.remoteAddr, err, buf)
}
if !c.hijacked() {
c.close()
c.setState(c.rwc, StateClosed)
}
}()
```

err 真这么好干嘛到处 recover ？

[fengjianxinghun]

h__t__t__p__s:\\golang.org\src\net\http\server.go

冒失没有手机号不让发 url


// Serve a new connection.
```
func (c *conn) serve(ctx context.Context) {
c.remoteAddr = c.rwc.RemoteAddr().String()
ctx = context.WithValue(ctx, LocalAddrContextKey, c.rwc.LocalAddr())
defer func() {
if err := recover(); err != nil && err != ErrAbortHandler {
const size = 64 << 10
buf := make([]byte, size)
buf = buf[:runtime.Stack(buf, false)]
c.server.logf("http: panic serving %v: %v\n%s", c.remoteAddr, err, buf)
}
if !c.hijacked() {
c.close()
c.setState(c.rwc, StateClosed)
}
}()
```

[rrfeng]

@mcfog
我觉得能写好 promise 的人一定能用 async/await，但是不会用 async/await 的肯定 promise 也不懂。
而且还有 async 属于新标准，很多人不一定知道并且用过……

[karllynn]

xerrors 可以输出栈了，所以都还好…泛型比较重要一些

[liuguang]

这个就是多返回值语言的优点，明明可以直接 return 多方便，try catch 和 defer 一样，只会让程序变得更慢。
defer 为了关闭资源还可以理解，而明明知道有 error，不直接处理，还在一堆代码里面 catch，不如直接 return 来的高效。

[fengjianxinghun]

@liuguang go 现在的多返回值实现是用栈来实现的，没办法像 c/c++用 rax 返回，速度慢了一大截。

[dbskcnc]

@fengjianxinghun err 或者 panic 都可以用,个人是喜欢 err, 但是有人喜欢用 panic,你也没办法,毕竟这里没有对错,只是风格喜好不同, 如果你调用的模块(库)用了 panic,只有 recover 应对, 自己写的几年 go 没用过 panic,但 recover 有时还是得用

[mcfog]

@rrfeng 所以说我观察下来就是能写写 promise 但一换 async await 就不行了的人挺多的。反过来 async await 写的好的，换 promise 也能写，就是幸福指数下降罢了，也就是说 async await 带来的字面上的简单让不少人误以为自己能轻松把异步代码写好了（然而并不）

我觉得 golang 关于语法糖的思路也是有这种拒绝虚假的幸福指数的倾向，不做让复杂的事情（异步／错误处理）表面上变简单，但并不降低实际复杂度的语法糖

[xfriday]

@neoblackcap 我认为就是 fp 那一套而已，本身没有区别，各种 or_else, map_err 我是没有看出什么优雅来，如果没有编译器优化，甚至效率都低下

[xfriday]

clear is better than clever，越是复杂的东西，推广和维护成本就越高，foo("".into())，我特么找个实现要到处去翻

[ChristopherWu]

@xfriday 本来编译器的目标之一就是优化- = -

[bobuick]

try catch 没什么卵用. 用 go 写 crud 的会感觉 try 必要性比较大, 用 go 写偏系统一点的东西, try 基本上没卵用了.

[xfriday]

rust 宣称的无数据竞争，仅仅是靠不可变来实现，这叫解决问题吗？根本就是回避问题，如果确实需要多线程共享变量，到头来还是要靠锁，rust 会打广告是真的

[fengjianxinghun]

@bobuick 别吹，go 标准库是偏系统没有 crud 吧？里面也一堆 panic/recover 当 try catch 用

[TheBestSivir]

@xfriday 不可变对象就是解决的数据竞争，代码如果是 immutable 风格的就是天然不存在并发问题的。至于线程间数据共享你认为还要上锁，是因为你用了 immutable 的 rust 写出了 java/c++的代码，不可变对象是通过 copy on read/write 来解决并发问题的。理论上不存在两个线程共享一个引用的问题

[xfriday]

@TheBestSivir Mutex，Arc、Rc、RefCell 是什么？什么叫“理论上不存在两个线程共享一个引用的问题“？真以为 rust 的 ownership 能解决所有问题？

[secondwtq]

async/await 是帮你做 CPS，这个是有一定复杂性的，已经超过了语法糖的范畴了。

[morethansean]

@mcfog 你确定吗……反正我遇到的真实业务里能用 promise 写清楚一个稍微复杂点逻辑的比 aa 少多了……虽然不深入了解 promise 的人对 aa 也就停留在最简单的使用上，但至少他们能用这个写出代码……

[secondwtq]

另外我倒是认为这个没必要关注也没必要吵，因为用 Go 的其实并不关注这些东西，关注这些东西的不用 Go。吵半天一点意义都没有