更优雅的 Golang 错误处理
Posted GoCN
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了更优雅的 Golang 错误处理相关的知识，希望对你有一定的参考价值。
转摘自：
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 现有的哲学中，要求你尽量手工处理所有的错误返回，这稍微增加了开发人员的心智负担。关于这部分设计的讨论，请参考本文最开始提供的参考链接，此处不做太多探讨。
本质上，Golang 中的错误类型 error 是一个接口类型：
type error interface {
Error() string
}只要满足这一接口定义的所有数值都可以传入 error 类型的位置。在 中也提到了关于错误的描述： Errors 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}
}实际上这里 Golang 标准库中返回了一个名为 PathError 的结构体，这个结构体定义了操作类型、路径和原始的错误信息，然后通过 Error 方法对所有信息进行了整合。
但是这样也会存在问题，比如需要进行单独类型复杂的分类处理，比如上面例子中，需要单独处理 PathError 这种问题，你可能需要一个单独的类型推导：
err := xxxx()if err != nil {
swtich err := err.(type) { case *os.PathError:
... default:
...
}
}这样反倒会增加错误处理的复杂度。同时，这些错误必须变为导出类型，也会增加整个系统的复杂度。
另外一个问题是，我们在出现错误时，我们通常也希望获取更多的堆栈信息，方便我们进行后续的故障追踪。在现有的错误体系中，这相对比较复杂：你很难通过一个接口类型获取完整的调用堆栈。这时，我们可能就需要一个第三方库区去解决遇到的这些错误处理问题。
还有一种情况是，我们希望在错误处理过程中同样可以附加一些信息，这些也会相对比较麻烦。
更优雅的错误处理
之前提到了多种实际应用场景中出现的错误处理方法和遇到的一些问题，这里推荐使用第三方库去解决部分问题：github.com/pkg/errors。
比如当我们出现问题时，我们可以简单的使用 errors.New 或者 errors.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。
以上是关于更优雅的 Golang 错误处理的主要内容，如果未能解决你的问题，请参考以下文章