将单个错误传递给errors.Join 有问题吗？

哈喽！大家好，很高兴又见面了，我是golang学习网的一名作者，今天由我给大家带来一篇《将单个错误传递给errors.Join 有问题吗？》，本文主要会讲到等等知识点，希望大家一起学习进步，也欢迎大家关注、点赞、收藏、转发! 下面就一起来看看吧！

go 1.20 引入了 errors.join 函数，可以包装多个错误。调用此函数并且仅传递一个错误是否存在任何问题？

例如，本文建议不要对可写文件使用 defer f.close() 习惯用法，因为这会默默地忽略 close 返回的任何错误。相反，它建议使用命名返回值 err 来允许传播 close 的返回值 - 除非这样做会覆盖之前的错误：

defer func() {
    cerr := f.close()
    if err == nil {
        err = cerr
    }
}()

在这种情况下使用 errors.join 似乎更正确：

defer func() {
    cerr := f.Close()
    err = errors.Join(err, cerr)
}()

如果 err 和 cerr 均非零，则现在将返回两个错误。如果都是nil，则返回nil。

但是，如果一个是 nil 而另一个是非 nil，则 errors.join 不仅会返回非 nil 错误，还会返回一个 errors.joinerror 围绕它的包装器。包装这样的错误会导致任何问题吗？特别是如果调用堆栈中的多个函数使用这种方法，那么单个错误可能会在多层包装器中结束？

正确答案

如果 errors.joinerror 只有一个非零错误，那仍然是一个连接错误，并且 errors.as 和 errors.is 函数按预期工作。无论连接错误的嵌套级别如何，这都是正确的。

唯一潜在的问题是如果有如下代码：

err:=someFunc()
if err==io.EOF {
  ...
}

那么这将会失败。必须重写此代码才能使用 errors.is。

到这里，我们也就讲完了《将单个错误传递给errors.Join 有问题吗？》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！