预计将于 2023 年 2 月发布的 Go 1.20 有一个小的变化，对于那些大量使用错误包装的应用程序来说，可能会有效改进它们的错误处理方法。

让我们看一下它的用法，但首先，需要简要回顾一下什么是错误包装。如果你已经掌握了可以直接跳到下面的 “Go 1.20 新功能” 部分以获取新的信息。

(资料图)

Go 中的错误是实现一个非常简单的接口：

typeerrorinterface{Error()string}

错误类型可以是任何东西，从string本身到int，但通常它们是struct类型。下面这个例子来自标准库：

typeerrstruct{sstring}func(e*err)Error()string{returne.s}

要检查 Go 中的错误，你只需比较一个值（在本例中为int值）：

iferr==io.EOF{//...}

第二种常见的用法是检查错误的类型，那也意味着要写更多的代码：

ifnerr,ok:=err.(net.Error){//...(usenerrwhichisanet.Error)}

在上面的例子中，类型断言测试类型net.Error的err值，并创建一个新变量nerr，它可以在 if 语句中使用。Go 中的错误方便理解、易于使用且非常高效。

从 Go 1.13 开始，引入了错误包装。包装允许将错误嵌入到其他错误中，就像在其他语言中包装异常一样。这非常实用，比如函数遇到 “record not found” 错误时，可以向错误信息中添加更多上下文信息，例如 “unknown user: record not found”。

Go 中错误包装设计背后的有趣想法是：契约不用关心错误类型、结构或它们是如何创建的。而唯一关注的是解包过程和转换为字符串，因为这两者是必须的。这就非常容易实现：支持解包的错误类型必须实现Unwrap() error方法。

标准库中没有（命名的）接口可以向您展示，因为接口是隐式实现的，没有必要单独写一个。这里我们写一个只是为了更好说明这篇文章：

typeWrappedErrorinterface{Unwrap()error}

我们来看看 Go 标准库（实际上是 package fmt）中是如何实现包装错误的：

typewrapErrorstruct{msgstringerrerror}func(e*wrapError)Error()string{returne.msg}func(e*wrapError)Unwrap()error{returne.err}

由于上面错误类型实现了Error() string方法，所以说 Go 中的错误实际上最终是字符串并没有错，因此需要一种创建这些字符串的良好机制。这就是标准库中的函数fmt.Errorf发挥作用的地方：

varRecordNotFoundErr=errors.New("notfound")constname,id="lzap",13werr:=fmt.Errorf("unknownuser%q(id%d):%w",name,id,recordNotFoundErr)fmt.Println(werr.Error())

一个特殊格式的动词%w，每次调用只能使用一次（稍后会详细介绍），用于错误参数。除此之外，该函数的工作方式类似于fmt.Printf函数。下面的例子打印了这个结果：

unknownuser"lzap"(id13):notfound

如你所见，错误包装本质上是一个链表。要解包错误，请使用errors.Unwrap函数，该函数将为链表中的最后一个错误值返回nil。要检查错误类型或值，需要遍历整个列表，这对于需要进行频繁的错误检查不太实用。幸运的是，有两个辅助函数可以做到这一点。

检查包装错误列表中的值：

iferrors.Is(err,RecordNotFoundErr){//...}

检查特定类型（下面例子是来自标准库的网络错误）:

varnerr*net.Erroriferrors.As(err,&nerr){//...(usenerrwhichisa*net.Error)}

以上总结了 Go 1.13 及更高版本中的错误包装。

让我们看看 Go 1.20 中真正的新功能，从函数errors.Join开始，它通过可变参数包装错误列表：

err1:=errors.New("err1")err2:=errors.New("err2")err:=errors.Join(err1,err2)fmt.Println(err)

当事先不知道错误数量时，此功能可用于将错误连接在一起。一个很好的例子是从 goroutines 收集错误。值得一提的是，该函数将列表中的错误与换行符连接起来。上面的代码片段打印：

err1err2

对于许多应用程序或（日志记录）库来说，这可能会存在问题，它们期望错误通常只是没有换行符的字符串。幸运的是，Go 1.20 中的另一个变化改变了fmt.Errorf的行为：该函数现在接受多个%w格式说明符：

err1:=errors.New("err1")err2:=errors.New("err2")err:=fmt.Errorf("%w+%w",err1,err2)fmt.Println(err)

以前会导致格式错误的格式字符串现在可以正确打印：

err1+err2

同时包装多个错误实现Unwrap() error，这是可能的吗?

事实证明，在 Go 1.20 标准库中有一种新的机制: 实现Unwrap() []error函数的错误类型可以包装多个错误。让我们来看看这是如何在库中实现的:

typejoinErrorstruct{errs[]error}func(e*joinError)Error()string{//concatenateerrorswithanewlinecharacter}func(e*joinError)Unwrap()[]error{returne.errs}

一个理论上的接口，但标准库中实际不存在，如下所示：

typeMultiWrappedErrorinterface{Unwrap()[]error}

由于 Go 不允许方法重载，因此每种类型都可以实现Unwrap() error或Unwrap() []error，但不能同时实现。还记得我提到过包装错误本质上是一个链表吗？实现前一个（新引入的）方法的类型实际上形成了一个链接树，函数errors.Is和errors.As的工作方式相同，只是现在它们需要遍历树而不是列表。根据文档，该实现执行预排序、深度优先遍历。

这确实是 Go 1.20 带来的全部，它可能看起来是一个小的变化，但它提供了如何有效和干净地处理错误的新方法。在展示真实示例之前，让我总结一下新功能：

新的Unwrap []error函数契约允许遍历错误树。

新的errors.Join函数，这是一个方便的函数，用于连接两个错误字符串值（使用换行符）。

现有函数errors.Is和errors.As已更新，可以同时处理错误列表和错误树。

上面这一切都很棒，但是你如何在实践中利用它呢？

在一个小型 REST API 微服务中，我们通过errors.New和fmt.Errorf处理来自 DAO 包（数据库）、REST 客户端（其他后端服务）和其他包的各种错误。返回的 HTTP 状态代码应该是 2xx、4xx 或 5xx，具体取决于错误状态以遵循最佳 REST API 实践。实现此过程的一种方法是解开主 HTTP 处理程序中的错误并找出它是哪种错误。

然而，通过多重错误包装，现在可以包装根本原因（例如数据库返回 “no records found” ）和返回给用户 HTTP 代码（在本例中为 404）。

一个工作示例如下所示：

packagemainimport("errors""fmt")//commonHTTPstatuscodesvarNotFoundHTTPCode=errors.New("404")varUnauthorizedHTTPCode=errors.New("401")//databaseerrorsvarRecordNotFoundErr=errors.New("DB:recordnotfound")varAffectedRecordsMismatchErr=errors.New("DB:affectedrecordsmismatch")//HTTPclienterrorsvarResourceNotFoundErr=errors.New("HTTPclient:resourcenotfound")varResourceUnauthorizedErr=errors.New("HTTPclient:unauthorized")//applicationerrors(thenewfeature)varUserNotFoundErr=fmt.Errorf("usernotfound:%w(%w)",RecordNotFoundErr,NotFoundHTTPCode)varOtherResourceUnauthorizedErr=fmt.Errorf("unauthorizedcall:%w(%w)",ResourceUnauthorizedErr,UnauthorizedHTTPCode)funchandleError(errerror){iferrors.Is(err,NotFoundHTTPCode){fmt.Println("Willreturn404")}elseiferrors.Is(err,UnauthorizedHTTPCode){fmt.Println("Willreturn401")}else{fmt.Println("Willreturn500")}fmt.Println(err.Error())}funcmain(){handleError(UserNotFoundErr)handleError(OtherResourceUnauthorizedErr)}

这将打印：

Willreturn404usernotfound:DB:recordnotfound(404)Willreturn401unauthorizedtocallotherservice:HTTPclient:unauthorized(401)

从这样的人工代码片段中可能看起来不太明显的是，实际上的错误声明通常分布在许多包中，并且不容易跟踪所有可能的错误以确保所需的 HTTP 状态代码。在这种方法中，所有在一个地方声明的应用程序级包装错误也包含了 HTTP 代码。

请注意，这在 Go 1.19 或更早版本中是不可能的，因为fmt.Errorf函数只会包装第一个错误。该代码确实在 1.19 上可以编译，甚至不会产生运行时恐慌，但它实际上不会工作。

显然，常见的 HTTP 状态代码很容易成为一种新的错误类型（基于int类型），因此可以通过errors.As轻松提取实际代码，但我想让示例保持简单。

在你的应用程序中实施新功能时，请注意errors.Unwrap函数。对于具有Unwrap() []error的错误类型，它总是返回nil：

err1:=errors.New("err1")err2:=errors.New("err2")err:=errors.Join(err1,err2)unwrapped:=errors.Unwrap(err)fmt.Println(unwrapped)

由于 Go 1.X 兼容性承诺，这会打印出 “nil”。当你引入多个包装错误时，请确保检查展开代码。幸运的是，典型 Go 代码中的大部分错误检查都是使用errors.Is和errors.As完成的。

校对：watermelo

往期推荐

最好的Go框架：没有框架？

想要了解Go更多内容，欢迎扫描下方关注公众号，回复关键词 [实战群],就有机会进群和我们进行交流

分享、在看与点赞Go