From ea118088ed02bf5109570e2b51f4b05e55fb5580 Mon Sep 17 00:00:00 2001 From: Tony Date: Fri, 14 May 2021 16:26:48 +0800 Subject: [PATCH] fix typo on ch1-07 --- ch1-basic/ch1-07-error-and-panic.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch1-basic/ch1-07-error-and-panic.md b/ch1-basic/ch1-07-error-and-panic.md index 5fc73bc..6ccb108 100644 --- a/ch1-basic/ch1-07-error-and-panic.md +++ b/ch1-basic/ch1-07-error-and-panic.md @@ -119,7 +119,7 @@ if _, err := html.Parse(resp.Body); err != nil { 上层用户在遇到错误时，可以很容易从业务层面理解错误发生的原因。但是鱼和熊掌总是很难兼得，在上层用户获得新的错误的同时，我们也丢失了底层最原始的错误类型（只剩下错误描述信息了）。 -为了记录这种错误类型在包装的变迁过程中的信息，我们一般会定义一个辅助的`WrapError`函数，用于包装原始的错误，同时保留完整的原始错误类型。为了问题定位的方便，同时也为了能记录错误发生时的函数调用状态，我们很多时候希望在出现致命错误的时候保存完整的函数调用信息。同时，为了支持RPC等跨网络的传输，我们可能要需要将错误序列化为类似JSON格式的数据，然后再从这些数据中将错误解码恢出来。 +为了记录这种错误类型在包装的变迁过程中的信息，我们一般会定义一个辅助的`WrapError`函数，用于包装原始的错误，同时保留完整的原始错误类型。为了问题定位的方便，同时也为了能记录错误发生时的函数调用状态，我们很多时候希望在出现致命错误的时候保存完整的函数调用信息。同时，为了支持RPC等跨网络的传输，我们可能要需要将错误序列化为类似JSON格式的数据，然后再从这些数据中将错误解码恢复出来。 为此，我们可以定义自己的`github.com/chai2010/errors`包，里面是以下的错误类型：