go 1.13的错误处理
本文有些难懂，建议看完这篇博客再看.
把错误当初数值的方式在过去的十年给我们提供许多便利，但是标准库中对错误的支撑却很少，比，只有errors.New和fmt.Errorf这两个函数，他们创造只包含一条信息的错误，内置的error接口允许go程序员添加他们想要的错误类型。只需要实现error方法。
type QueryError struct {
Query string
Err error
}
func (e *QueryError) Error() string { return e.Query + ": " + e.Err.Error() }
像这类的error 类型无所不在，并且他们所储存的信息十分广泛，从时间戳到文件名到服务器IP。通常，这个信息还包括其他信息，比如较为低级的错误信息，以便提供额外的上下文信息。在一个错误中包含另一个错误，这样的模式在go中普遍存在，所以在经过了广泛的讨论后，go 1.13决定对其添加显式的支持。本文描述了三个errors包的新函数和一个fmt.Errorf的新动词。
在讨论这些改变之前，我们先复习一下，在之前的版本中，我们是如何去检测和构建一个错误的。
go 1.13 前的错误
检测错误
go的错误是数值，在多数情况下，程序基于这些数值做出决策。最常见的方法是把错误和nil相比较，去判断一个人操作是否失败。
if err != nil {
// something went wrong
}
有时候，我们会把错误和一个哨兵值相对比，从而判断是否发生了特定的错误。
var ErrNotFound = errors.New("not found")
if err == ErrNotFound {
// something wasn't found
}
一个错误类型可能是任何满足了语言定义的error接口的类型，程序可以使用类型断言和类型转换去更详细的观察错误。
type NotFoundError struct {
Name string
}
func (e *NotFoundError) Error() string { return e.Name + ": not found" }
if e, ok := err.(*NotFoundError); ok {
// e.Name wasn't found
}
额外信息
在函数向调用堆栈添加信息是，通常会把错误向上传递给调用堆栈，例如一段简单的信息，描述了什么时候发生的错误。一个简单的实现方式是构造一个包含了之前错误的错误。
if err != nil {
return fmt.Errorf("decompress %v: %v", name, err)
}
用fmt.Errorf创建一个错误会丢失掉原始错误中除了内容之外的东西。正如我们上文所看到的QueryError，我们想要定义一个错误，他包含了之前的错误，以便在代码中我们能检查它。
type QueryError struct {
Query string
Err error
}
程序可以通过观察 *QueryError内部，基于表面下的错误做出决策，这种情况有事被称为错误展开。（unwrapping）
if e, ok := err.(*QueryError); ok && e.Err == ErrPermission {
// query failed because of a permission problem
}
os.PathError 在标准库中也是另一个例子，一个错误包含着另一个错误。
go 1.1中的错误
展开方法
go 1.13 引进了新特性给error和fmt标准库，以简化错误中包含着错误的工作。其中最重要的一点说是改变倒不如说是约定：包含着其他错误的错误可以实现Unwrap方法，它返回内层错误。如果e1.Unwrap()返回e2，那么我们说e1包含e2，或者展开e1得到e2。
遵循以下约定，我们可以得到QueryError 类型，并且实现Unwrap方法，返回其内层方法。
func (e *QueryError) Unwrap() error { return e.Err }
将错误展开后，我们可能也会得到一个包含着另一个有着Unwrap方法的错误。我们将这种情况称之为重复展开错误链 而产生了一个错误序列。
用IS和AS检测错误
在go1.13中，error包有了两个新函数以检测错误，一个是Is一个是As。
errors.Is函数比较错误与值。
//类似以下情况
// if err == ErrNotFound { … }
if errors.Is(err, ErrNotFound) {
// something wasn't found
}
As函数检查一个错误是否为特定的类型
// 类似以下情况
// if e, ok := err.(*QueryError); ok { … }
var e *QueryError
if errors.As(err, &e) {
// err is a *QueryError, and e is set to the error's value
}
在最简单的情况下，errors.Is 函数的作用类似于与哨兵值比较，而 errors.As 函数的行为更接近于类型声明。对包裹过的错误进行操作时，这些函数会考虑链中的所有错误。我们再使用QueryError来说明两个新函数的使用。
if e, ok := err.(*QueryError); ok && e.Err == ErrPermission {
// 由于权限问题，查询失败
}
使用errors.Is函数后
if errors.Is(err, ErrPermission) {
// err 本身或者 err 包裹的错误，是一个权限问题
}
errors包内有一个新的Unwrap方法，他的返回值是调用错误的Unwrap方法返回的结果，如果错误没有Unwrap方法，就会返回nil，最好还是使用errors.Is和errors.As，这些方法都会在一次调用中检查整条错误链。
用 %w 包装错误
正如之前提到的，通常方法是用fmt.Errorf函数去添加额外信息。
if err != nil {
return fmt.Errorf("decompress %v: %v", name, err)
}
在 Go 1.13 中，fmt.Errorf 函数支持新的 ％w 动词。当存在该动词时，fmt.Errorf 返回的错误将具有 Unwrap 方法，该方法返回 ％w 的参数，该参数必须是错误。在其他方面，％w 与 ％v 相同。
if err != nil {
// Return an error which unwraps to err.
return fmt.Errorf("decompress %v: %w", name, err)
}
用%w包装一个错误，使得它可以使用errors.Is和errors.As
err := fmt.Errorf("access denied: %w", ErrPermission)
...
if errors.Is(err, ErrPermission) ...
是否需要包装错误
向错误中添加额外上下文的时候，使用fmt.Errorf或者通过实现自定义类型。你需要决定是否需要包装之前的错误。这个问题没有一个答案。它取决于创建新错误的上下文。包装错误可以将原始错误暴露给调用者。当不希望暴露细节的时候请不要包装错误。
译注：细节指错误信息附带的其他敏感信息，比如路径信息等，当用户调用错误时，系统不希望用户通过错误信息得知数据库等地址
举个例子来说，一个Parse函数，他读取复杂的数据结构从io.Reader中，如果一个错误发生，我们希望它能报告出发生错误的行和列，如果从 io.Reader 读取时发生错误，我们将希望包装该错误以允许检查基本问题。由于调用者向函数提供了 io.Reader，因此暴露由它产生的错误是有意义的。
相反，对数据库进行多次调用的函数不应该返回将展开后的错误。如果该函数使用的数据库是实现细节，那么暴露这些错误就违背了抽象的原则。例如，如果你编写的 LookupUser 函数使用 Go 的 database / sql 包，则它可能会遇到 sql.ErrNoRows 错误。如果你使用 fmt.Errorf(“ accessing DB：％v”，err) 返回该错误，则调用者无法在程序内部查找 sql.ErrNoRows。但是如果函数反而返回 fmt.Errorf(“ accessing DB：％w”，err)，则调用者可以这样编写代码：
err := pkg.LookupUser(...)
if errors.Is(err, sql.ErrNoRows) …
此时，即使你不希望中断客户端，即使切换到其他数据库包，该函数也必须始终返回sql.ErrNoRows。 换句话说，包装错误会使该错误成为API的一部分。 如果您不想将来将错误作为API的一部分来支持，则不应包装该错误。
请务必记住，无论是否包装错误，错误文本都将相同。 将以两种方式获得相同的信息。 包装的选择是关于是否给程序提供更多信息，以便他们可以做出更明智的决定，还是保留该信息以保留抽象层。
使用Is和As定制错误
errors.Is将会检测每个错误是否与目标错误相同，默认情况下，当两个错误相等时，他们相匹配。除此之外，也可以通过实现Is方法来声明和某个目标值是相等的。
例如，受Upspin 错误包错误包启发的，该包将错误与模板进行比较，仅考虑模板中非零的字段：
type Error struct {
Path string
User string
}
func (e *Error) Is(target error) bool {
t, ok := target.(*Error)
if !ok {
return false
}
return (e.Path == t.Path || t.Path == "") &&
(e.User == t.User || t.User == "")
}
if errors.Is(err, &Error{User: "someuser"}) {
// err's 的用户定义字段是 "someuser".
}
error.As类似。
错误和包API
返回错误的包(大多数都是这样)，应该描述程序员可能依赖的那些错误的属性。一个设计良好的包还可以避免返回带有不应该依赖的属性的错误。
最简单的规范是说操作成功或失败，分别返回nil或nonnil错误值。 在许多情况下，不需要进一步的信息。
如果我们希望函数返回一个可识别的错误条件，例如“item not found”，我们可能需要返回一个包装了标记的错误。
var ErrNotFound = errors.New("not found")
// FetchItem 返回指定名称的项目
//
// 如果指定名称项目不存在，则返回包装了的错误
func FetchItem(name string) (*Item, error) {
if itemNotFound(name) {
return nil, fmt.Errorf("%q: %w", name, ErrNotFound)
}
// ...
}
还有其他现有的提供错误的模式，可以由调用方进行语义检查，例如直接返回哨兵值，特定类型或可以使用谓词函数检查的值。
在所有类型中，我们都要注意是否需要将细节暴露给用户，正如我们上文讨论过的”是否需要包装“，当你从另一个包中返回错误时，应该将错误转换为不暴露基本错误的形式，除非你承诺返回该特定错误。
f, err := os.Open(filename)
if err != nil {
// 由 os.Open 返回的 *os.PathError 属于内部细节
// 为了避免将其暴漏给调用方，将其重新包裹为
// 一个具有相同文字信息的错误。这里使用 %v 格式化谓词，
// 因为 %w 有内部 *os.PathError 被展开的可能。
return fmt.Errorf("%v", err)
}
如果将函数定义为返回包装某些标记或类型的错误，请不要直接返回基础错误。
var ErrPermission = errors.New("permission denied")
// DoSomething 会在用户没有做某些事群的许可时
// 返回一个包裹 ErrPermission 的错误
func DoSomething() error {
if !userHasPermission() {
// 如果直接返回 ErrPermission，那调用方就可能
// 依赖确切的返回值，然后写出这样的代码
//
// if err := pkg.DoSomething(); err == pkg.ErrPermission { … }
//
// 这样的话如果我们以后想要给错误加入其他上下文，
// 是会出问题的。为了避免这种事情，我们使用错误包裹
// 哨兵，这样用户每次都必须将其展开：
//
// if err := pkg.DoSomething(); errors.Is(err, pkg.ErrPermission) { ... }
return fmt.Errorf("%w", ErrPermission)
}
// ...
}