据说 Go 2.0 的错误处理有可能是这个样子

[SuperMild]

func foobar(a, b int) error {
    handle err { return err } // This is our handler
    x := check foo(a, b) // check invokes the handle func
    y := check bar(a, b) // this on as well
}

看起来还蛮好的。

来源: https://levelup.gitconnected.com/golang-2-0-draft-feature-error-handling-c0a2332b9162

但我觉得还能改进，比如把 handle err { return err } 当作默认行为，不需要写这句就是这个行为，如果写了就覆盖默认行为。

[yxwzaxns]

再把 check 去掉就更好了

[SuperMild]

@yxwzaxns 那就是风格问题，不是好坏的问题。

一般应该在保持风格不变的前提下讨论，因为讨论风格很容易变成无意义的争吵。

[liuxu]

这个方式很 golang ，不错

[aababc]

rust： 快来抄作业呀

[joesonw]

这和老早的 try 的 proposal 不是一样的吗

[liuxu]

@aababc 要是能把 rust 的？实现那是极好的，怎么写怎么舒心

[kidonng]

底下评论：

This version with check/handle is actually a rejected old draft which was reworked as try/defer, rejected again, and eventually gave the 1.13 error handling we now have.

珍惜 if (err != nil) 吧，这可是 Go 为数不多的 boilerplate 🐶

[Buges]

糟糕的设计。加了泛型以后 interface 已经支持 union type 了，弄个 Result 把 rust 的?抄过来就是。

[okayan]

这不是很早之前的 proposal 么

[SuperMild]

@Buges

这个设计是兼容 Result 的，比如

```
func foobar(a, b int) Result {
handle err { return NewResult(err) }
}
```

如果彻底抛弃 error 改用 Result ，标准库以及第三方库就要全部重构了，显然是一个非常激进的决策，很难说比现在这个谨慎的决策更好吧。

后续如果社区越来越喜欢用 Result ，倒是再对 Result 提供特殊支持也不晚呀。

[SuperMild]

@okayan 我之前没有专门去留意，今天看到 Medium Daily Digest 给我推荐才顺手点开看看。

[SuperMild]

@liuxu 可以暂时先留给第三方库去做，有了泛型之后自己包裹一个 Result 出来也行（想来应该会有人去做这个事，到时直接用就行）

[Buges]

@SuperMild 不需要全部重构，双返回值到 Result 一个函数就可以解决。
x:=check(foo(a,b))?

[iseki]

又多出俩关键字来…能不能尽量用设计良好的语法和充分利用语法特性的标准库来实现，而不是想到什么就加点魔法…

[ncepuzs]

当初没有设计完善就草草发布 1.0 版本的后遗症，只能走一步看一步，缝缝补补

[sagaxu]

这么快就背上历史包袱了

[kidlj]

这是 2018 年的设计，早就被否了。

[fengjianxinghun]

@iseki 残废的类型系统导致很多东西没法用标准库扩展，只能开特权加魔法

[iseki]

@fengjianxinghun 诶…可 Go 好歹也算是个新语言啊，现在就这样了，以后可咋办啊…

[SuperMild]

@iseki
@fengjianxinghun

Go 1 稳定了十年，现在 Go 2 大版本升级才加少量关键词，应该很正常吧？

Java 或 C# 之类的，大版本升级从未加过关键词吗？（而且，大版本升级加少量关键词在语言设计圈会被鄙视吗？感觉应该不至于是这样的风气才对。）