你对 Go 错误处理的 4 个误解！

Go 语言中错误处理的机制一直是各大 Gopher 热议的问题。甚至一直有人寄望 Go 支持 throw 和 catch 关键字，实现与其他语言类似的特性。社区里的讨论也从未停过。

今天煎鱼带大家了解几个 Go 语言的错误处理中，大家最关心，也是最容易被误解、被嫌弃的问题：

1. 为什么不支持 try-catch？
2. 为什么不支持全局捕获的机制？
3. 为什么要这么设计错误处理？
4. 未来的错误处理机制会怎么样？

在 Go1 时，大家知道基本不可能支持。于是打起了 Go2 的主意。为什么 Go 就不能支持 try-catch 组合拳？

上一年宣发了 Go2 的构想，所以在 2020 年就有小伙伴乘机提出过类似 《proposal: Go 2: use keywords throw, catch, and guard to handle errors^[1]》的提案，这可是其他语言都支持的，Go 语言怎么了？

下面来自该提案的演示，Go1 的错误处理：

type data struct {}

func (d data) bar() (string, error) {
    return "", errors.New("err")
}

func foo() (data, error) {
    return data{}, errors.New("err")
}

func do () (string, error) {
    d, err := foo()
    if err != nil {
        return "", err
    }

    s, err := d.bar()
    if err != nil {
        return "", err
    }

    return s, nil
}

新提案所改造的方式：

type data struct {}

func (d data) bar() string {
    throw "", errors.New("err")
}

func foo() (d data) {
    throw errors.New("err")
    return
}

func do () (string, error) {
    catch err {
        return "", err 
    }

    s := foo().bar()
    return s, nil
}

不过答复非常明确，@davecheney 在底下回复“以最强烈的措辞，不（In the strongest possible terms, no）”。这可让人懵了圈，为什么这么硬呢？

其实 Go 官方早在《Error Handling — Problem Overview^[2]》提案早已明确提过，Go 官方在设计上会有意识地选择使用显式错误结果和显式错误检查。

结合《language: Go 2: error handling meta issue^[3]》可得知，要拒绝 try-catch 关键字的主要原因是：

• 会涉及到额外的流程控制，因为使用 try 的复杂表达式，会导致函数意外返回。
• 在表达式层面上没有流程控制结构，只有 panic 关键字，它不只是从一个函数返回。

说白了，就是设计理念不合，加之实现上也不大合理。在以往的多轮讨论中早已被 Go 团队拒绝了。

反之 Go 团队倒是一遍遍在回答这个问题，已经不大耐烦了，直接都整理了 issues 版的 FAQ 了。

想捕获所有 panic

在 Go 语言中，有一个点，很多新同学会不一样碰到的。那就是在 goroutine 中如果 panic 了，没有加 recover 关键字（有时候也会忘记），就会导致程序崩溃。

又或是以为加了 recover 就能保障一个 goroutine 下所派生出来的 goroutine 所产生的 panic，一劳永逸。

但现实总是会让人迷惑，我经常会看到有同学提出类似的疑惑：

这时候，有其他语言经验的同学中，又有想到了一个利器。能不能设置一个全局的错误处理 handler。

像是 PHP 语言也可以有类似的方法：

set_error_handler();
set_exception_handler();
register_shutdown_function();

显然，Go 语言中并没有类似的东西。归类一下，我们聚焦以下两个问题：

1. 为什么 recover 不能捕获更上层的 panic？
2. 为什么 Go 没有全局的错误处理方法？

源码层面

如果是讲设计的话，其实只是通过 Go 的 GMP 模型和 defer+panic+recver 的源码剖析就能知道了。

本质上 defer+panic 都是挂载在 G 上的，可查看我以前写的《深入理解 Go panic and recover^[4]》，你会有更多深入的理解。

设计思想

在本文中我们不能仅限于源码，需要更深挖，Go 设计者他的思想是什么，为什么就是不支持？

在 Go issues 中《proposal: spec: allow fatal panic handler^[5]》、《No way to catch errors from goroutines automatically^[6] 》分别的针对性探讨过上述问题。

Go 团队的大当家 @Russ Cox 给出了明确的答复：Go 语言的设计立场是错误恢复应该在本地完成，或者完全在一个单独的进程中完成。

这就是为什么 Go 语言不能跨 goroutines 从 panic 中恢复，也不能从 throw 中恢复的根本原因，是语言设计层面的思想所决定。

在源码剖析时，你所看到的整套 GMP+defer+panic+recover 的机制机制，就是跟随着这个设计思想去编写和发展的。

设计思想决定源码实现。

建议方式

从 Go 语言层面去动摇这个设计思想，目前来看可能性很低。至少 2021 年的现在没有看到改观。

整体上会建议提供公共的 Go 方法去规避这种情况。参考 issues 所提供的范例如下：

recovery.SafeGo(logger, func() {
    method(all parameters)
})

func SafeGo(logger logging.ILogger, f func()) {
 go func() {
  defer func() {
   if panicMessage := recover(); panicMessage != nil {
    ...
   }
  }()

  f()
 }()
}

是不是感觉似曾相识？

每家公司的内部库都应该有这么一个工具方法，规避偶尔忘记的 goroutine recover 所引发的奇奇怪怪问题。

也可以参照建议，利用一个单独的进程（Go 语言中是 goroutine）去统一处理这些 panic，不过这比较麻烦，较少见。

未来会如何

Go 社区对 Go 语言未来的错误处理机制非常关心，因为 Go1 已经米已成炊，希望在 Go2 上解决错误处理机制的问题。

期望 Go2 核心要处理的包含如下几点（#40432）：

1. 对于 Go2，我们希望使错误检查更加轻便，减少专门用于错误检查的 Go 程序代码的数量。我们还想让写错误处理更方便，减少程序员花时间写错误处理的可能性。
2. 错误检查和错误处理都必须保持明确，即在程序文本中可见。我们不希望重复异常处理的陷阱。
3. 现有的代码必须继续工作，并保持与现在一样的有效性。任何改变都必须与现有的代码相互配合。

为此，许多人提过不少新的提案...很可惜，截止 2021.08 月底为止，有许多人试图改变语言层面以达到这些目标，但没有一个新的提案被接受。

现在也有许多变更并入 Go2 提案，主要是 error-handling 方面的优化。

大家有兴趣可以看看我之前写的：《先睹为快，Go2 Error 的挣扎之路》，相信能给你带来不少新知识。

总结

看到这里，我们不由得想到。为什么，为什么在 21 世纪前者已经有了这么多优秀的语言，Go 语言的错误处理机制依然这么的难抉择？

显然 Go 语言的开发团队是有自己的设计哲学和思想的，否则 “less is more” 也不会如此广泛流传。设身处地的理解 Go 官方的想法，而不是一味地单向理解，会对我们未来的编程之路更好。

当然，这存在着一系列既要也要的问题，不好处理。欢迎大家关注煎鱼，后续我们也可以面向 Go 后续的错误处理持续的关注和讨论！

参考资料

你好，我是煎鱼。高一折腾过前端，参加过国赛拿了奖，大学搞过 PHP。现在整 Go，在公司负责微服务架构等相关工作推进和研发。

从大学开始靠自己赚生活费和学费，到出版 Go 畅销书《Go 语言编程之旅》，再到获得 GOP（Go 领域最有观点专家）荣誉，点击蓝字查看我的出书之路。

日常分享高质量文章，输出 Go 面试、工作经验、架构设计，加微信拉读者交流群，记得点赞！