hosteons中文网

考虑一下 OS 包中的文件操作返回的错误集合，I/O 会因为很多原因失败，但有三类原因通常必须单独处理：文件已存储（创建操作），文件没找到（读取操作）以及权限不足。OS 包提供了三个帮助函数用来对错误进行分类：

package os

func IsExist(err error) bool
func IsNotExist(err error) bool
func IsPermission(err error) bool

一个幼稚的实现会通过检查错误消息是否包含特定的字符串来做判断：

func IsNotExist(err error) bool {
    //注意：不健壮
    return strings.Contains(err.Error(), "file does not exist")
}

但由于处理 I/O 错误的逻辑会随着平台的变化而变化，因此这种方法很不健壮，同样的错误可能会用完全不同的错误消息来报告。检查错误消息是否包含特定的字符串，这种方法在单元测试中还算够用，但对于生产级的代码则远远不够。

一个更可靠的方法是用专门的类型来表示结构化的错误值。OS 包定义了一个 PathError 类型来表示在与一个文件路径相关的操作上发生错误（比如 Open 或者 Delete），一个类似的 LinkError 用来表述在与两个文件路径相关的操作上发生错误（比如 Symlink 和 Rename）。下面是 os.PathError 的定义：

package os

// PathError 记录了错误以及错误相关的操作和文件路径
type PathError struct {
    Op string
    Path string
    Err error
}
func (e *PathError) Error() string {
    return e.Op + " " + e.Path + ": " + e.Err.Error()
}

很多客户端忽略了 PathError，改用一种统一的方法来处理所有的错误，即调用 Error 方法。PathError 的 Error 方法只是拼接了所有的字段，而 PathError 的结构则保留了错误所有的底层信息。对于那些需要区分错误的客户端，可以使用类型断言来检查错误的特定类型，这些类型包含的细节远远多于一个简单的字符串。

_, err := os.Open("/no/such/file")
fmt.Println(err) // "open /no/such/file: No such file or directory"
fmt.Printf("％#v\n", err)
//输出：
// &os.PathError{Op: "open", Path: "/no/such/file", Err:0x2}

这也是之前三个帮助函数的工作方式。比如，如下所示的 IsNotExist 判断错误是否等于 syscall.ENOENT，或者等于另一个错误 os.ErrNotExist，或者是一个 *PathError，并且底层的错误是上面二者之一。

import (
    "errors"
    "syscall"
)
var ErrNotExist = errors.New("file does not exist")

// IsNotExist返回一个布尔值，该值表明错误是否代表文件或目录不存在
// report that a file or directory does not exist. It is satisfied by
// ErrNotExist 和其他一些系统调用错误会返回 true
func IsNotExist(err error) bool {
    if pe, ok := err.(*PathError); ok {
        err = pe.Err
    }
    return err == syscall.ENOENT || err == ErrNotExist
}

实际使用情况如下：

_, err := os.Open("/no/such/file")
fmt.Println(os.IsNotExist(err))   // "true"

当然，如果错误消息已被 fmt.Errorf 这类的方法合并到一个大字符串中，那么 PathError 的结构信息就丢失了。错误识别通常必须在失败操作发生时马上处理，而不是等到错误消息返回给调用者之后。