转摘自：

Golang 中的错误处理是一个被大家经常拿出来讨论的(另外一个是)。其中泛型这个问题，rsc 在最近的计划中也了纳入他今年的考虑计划中，同时，在2016年也进行了一些更新，相信未来会有一些更好的方案提出。这个文章我们讨论一下如何在现行的 Golang 框架下提供更友好和优雅的错误处理。

从现状谈起

Golang 中的错误处理原则，开发者曾经之前专门发布了几篇文章( 和 、 )介绍。分别介绍了 Golang 中处理一般预知到的错误与遇到崩溃时的错误处理机制。

一般情况下，我们还是以官方博客中的错误处理例子为例：

func main() {
    f, err := os.Open("filename.ext")    if err != nil {
        log.Fatal(err)        // 或者更简单的：
        // return err
    }
    ...
}

当然对于简化代码行数，还有另外一种写法：

func main() {
    ...    if f, err = os.Open("filename.ext"); err != nil{
        log.Fatal(err)
    }
    ...
}

正常情况下，Golang 现有的哲学中，要求你尽量手工处理所有的错误返回，这稍微增加了开发人员的心智负担。关于这部分设计的讨论，请参考本文最开始提供的参考链接，此处不做太多探讨。

error
type error interface {
    Error() string
}
errorErrors are values

Errors are values

事实上，在实际使用过程中，你可能也发现了对 Golang 而言，所有的信息是非常不足的。比如下面这个例子：

buf := make([]byte, 100)
n, err := r.Read(buf)
buf = buf[:n]if err == io.EOF {
 log.Fatal("read failed:", err)
}
2017/02/08 13:53:54 read failed:EOF

于是乎，一些提供了上下文方式的一些错误处理形式便在很多类库中非常常见：

err := os.Remove("/tmp/nonexist")
log.Println(err)

输出了：

2017/02/08 14:09:22 remove /tmp/nonexist: no such file or directory

这种方式提供了一种更加直观的上下文信息，比如具体出错的内容，也可以是出现错误的文件等等。通过查看Remove的实现，我们可以看到：

// PathError records an error and the operation and file path that caused it.type PathError struct {
    Op   string
    Path string
    Err  error
}func (e *PathError) Error() string { return e.Op + " " + e.Path + ": " + e.Err.Error() }// file_unix.go 针对 *nix 系统的实现// Remove removes the named file or directory.// If there is an error, it will be of type *PathError.func Remove(name string) error {    // System call interface forces us to know
    // whether name is a file or directory.
    // Try both: it is cheaper on average than
    // doing a Stat plus the right one.
    e := syscall.Unlink(name)    if e == nil {        return nil
    }
    e1 := syscall.Rmdir(name)    if e1 == nil {        return nil
    }    // Both failed: figure out which error to return.
    // OS X and Linux differ on whether unlink(dir)
    // returns EISDIR, so can't use that. However,
    // both agree that rmdir(file) returns ENOTDIR,
    // so we can use that to decide which error is real.
    // Rmdir might also return ENOTDIR if given a bad
    // file path, like /etc/passwd/foo, but in that case,
    // both errors will be ENOTDIR, so it's okay to
    // use the error from unlink.
    if e1 != syscall.ENOTDIR {
        e = e1
    }    return &PathError{"remove", name, e}
}
PathErrorError
PathError
err := xxxx()if err != nil {
    swtich err := err.(type) {    case *os.PathError:
        ...    default:
        ...
    }
}

这样反倒会增加错误处理的复杂度。同时，这些错误必须变为导出类型，也会增加整个系统的复杂度。

另外一个问题是，我们在出现错误时，我们通常也希望获取更多的堆栈信息，方便我们进行后续的故障追踪。在现有的错误体系中，这相对比较复杂：你很难通过一个接口类型获取完整的调用堆栈。这时，我们可能就需要一个第三方库区去解决遇到的这些错误处理问题。

还有一种情况是，我们希望在错误处理过程中同样可以附加一些信息，这些也会相对比较麻烦。

更优雅的错误处理

github.com/pkg/errors
errors.Newerrors.Errorf
err := errors.New("whoops")// orerr := errors.Errorf("whoops: %s", "foo")

当我们需要附加信息时，则可以使用：

cause := errors.New("whoops")
err := errors.Wrap(cause, "oh noes")

当需要获取调用堆栈时，则可以使用：

err := errors.New("whoops")
fmt.Printf("%+v", err)

其他建议

在上面做类型推导时，我们发现在处理一类错误时可能需要多个错误类型，这可能在某些情况下相对来说比较复杂，很多时候我们可以使用接口形式去方便处理：

type temporary interface {
    Temporary() bool}// IsTemporary returns true if err is temporary.func IsTemporary(err error) bool {
    te, ok := errors.Cause(err).(temporary)    return ok && te.Temporary()
}

这样就可以提供更加方便的错误解析和处理。

广告时间

我们正在招收新人 Gopher，应届毕业生 or 实习生欢迎投递简历。我们正在努力实现开发流程标准化，如果你想获得提高，相信也是一个非常不错的机会。简历投递 kevin [at] yeeuu [dot] com。