我们可以使用恢复函数来处理所有恐慌，而不是将错误视为值吗？

Golang小白一枚，正在不断学习积累知识，现将学习到的知识记录一下，也是将我的所得分享给大家！而今天这篇文章《我们可以使用恢复函数来处理所有恐慌，而不是将错误视为值吗？》带大家来了解一下##content_title##，希望对大家的知识积累有所帮助，从而弥补自己的不足，助力实战开发！

我知道 go 处理错误的惯用方法是将其视为一个值，使用 if 语句检查它是否为 nil。 然而，在一个很长的函数中，它很快就会变得乏味，您需要在多个地方执行 if err!=nil{...} 。 我知道错误处理是 go 社区的痛点之一。

我只是在想为什么我们不能做这样的事情，

func Xyz(param1 map[string]interface{}, param2 context string) (return1 map[string]interface{}, err error)
{
defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("error: %s\n", r)
        }
    }()
.....
.....
.....
// Code causes a panic
}

在你的函数中有一个延迟函数调用，它使用了恢复，这样如果发生任何恐慌，调用堆栈将开始展开，并且将调用恢复函数，导致程序不会终止，处理自身并将错误返回到调用者。

这是一个 go 演示示例， https://play.golang.org/p/-bg-xefso-q

我的问题是这种方法的缺点是什么？我们会因此失去什么吗？

据我了解，recover 函数仅适用于同一个 goroutine。我们假设这是在同一个 goroutine 上。

解决方案

可以吗？是的。

事实上，即使在标准库中，也有少数情况会这样做。有关示例，请参阅 encoding/json。

但这只能在您的私有 API 范围内完成。也就是说，您不应该编写一个 API，其公开的行为包括可能的恐慌错误状态。因此，请确保在将值返回给 API 的使用者之前恢复所有恐慌，并将它们转换为错误（或以其他方式处理它们）。

我想到了一些事情：

1. 这显然违反了 the principle of least astonishment，因此您绝对不应该让这种做法跨越您的公共 API 边界。
2. 这很麻烦，任何时候您需要根据错误类型/内容采取行动，因为它需要您恢复错误，将其转换回其原始类型（可能是也可能不是 error 类型），然后执行您的操作检查/行动，然后可能会再次恐慌。只需一个简单的 error 值即可简单得多。
3. 与#2 密切相关，将错误视为值可以让您对何时以及如何响应错误条件进行大量细粒度控制。 panic 在这方面是一个非常生硬的工具，所以你失去了很多控制。
4. panic + recover 的执行效果不如简单地返回错误。在错误确实是异常的情况下，这可能并不重要（即在 encoding/json 示例中，当写入失败时使用它，这将中止整个操作，因此高效并不重要）。

我确信人们还可以想出其他原因。谷歌上有很多关于这个主题的博客文章。供您继续阅读，here's one random example。

本篇关于《我们可以使用恢复函数来处理所有恐慌，而不是将错误视为值吗？》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！