从现状谈起
Go语言受到诟病最多的一项就是其错误处理机制。如果显式地检查和处理每个error，这恐怕的确会让人望而却步。下面我们将给大家介绍Go语言中如何更优雅的错误处理。
Golang 中的错误处理原则，开发者曾经之前专门发布了几篇文章( Error handling and Go 和 Defer, Panic, and Recover、Errors are values )介绍。分别介绍了 Golang 中处理一般预知到的错误与遇到崩溃时的错误处理机制。
一般情况下，我们还是以官方博客中的错误处理例子为例：
|
1
2
3
4
5
6
7
8
9
|
func main() { f, err := os.Open("filename.ext") if err != nil { log.Fatal(err) // 或者更简单的： // return err } ...} |
当然对于简化代码行数，还有另外一种写法：
|
1
2
3
4
5
6
7
|
func main() { ... if f, err = os.Open("filename.ext"); err != nil{ log.Fatal(err) } ...} |
正常情况下，Golang 现有的哲学中，要求你尽量手工处理所有的错误返回，这稍微增加了开发人员的心智负担。关于这部分设计的讨论，请参考本文最开始提供的参考链接，此处不做太多探讨。
本质上，Golang 中的错误类型 error 是一个接口类型：
|
1
2
3
|
type error interface { Error() string} |
只要满足这一接口定义的所有数值都可以传入 error 类型的位置。在 Go Proverbs 中也提到了关于错误的描述： Errors are values。这一句如何理解呢？
Errors are values
事实上，在实际使用过程中，你可能也发现了对 Golang 而言，所有的信息是非常不足的。比如下面这个例子：
|
1
2
3
4
5
6
|
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，这对我们真实环境下的错误调试与分析其实是并没有任何意义的，我们在查看日志获取错误信息的时候能够获取到的信息十分有限。
于是乎，一些提供了上下文方式的一些错误处理形式便在很多类库中非常常见：
|
1
2
|
err := os.Remove("/tmp/nonexist")log.Println(err) |
输出了：
|
1
|
2017/02/08 14:09:22 remove /tmp/nonexist: no such file or directory |
这种方式提供了一种更加直观的上下文信息，比如具体出错的内容，也可以是出现错误的文件等等。通过查看Remove的实现，我们可以看到：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
// 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 这种问题，你可能需要一个单独的类型推导：
|
1
2
3
4
5
6
7
8
9
|
err := xxxx()if err != nil { swtich err := err.(type) { case *os.PathError: ... default: ... }} |
这样反倒会增加错误处理的复杂度。同时，这些错误必须变为导出类型，也会增加整个系统的复杂度。
另外一个问题是，我们在出现错误时，我们通常也希望获取更多的堆栈信息，方便我们进行后续的故障追踪。在现有的错误体系中，这相对比较复杂：你很难通过一个接口类型获取完整的调用堆栈。这时，我们可能就需要一个第三方库区去解决遇到的这些错误处理问题。
还有一种情况是，我们希望在错误处理过程中同样可以附加一些信息，这些也会相对比较麻烦。
更优雅的错误处理
之前提到了多种实际应用场景中出现的错误处理方法和遇到的一些问题，这里推荐使用第三方库去解决部分问题：github.com/pkg/errors。
比如当我们出现问题时，我们可以简单的使用 errors.New 或者 errors.Errorf 生成一个错误变量：
|
1
2
3
|
err := errors.New("whoops")// orerr := errors.Errorf("whoops: %s", "foo") |
当我们需要附加信息时，则可以使用：
|
1
2
|
cause := errors.New("whoops")err := errors.Wrap(cause, "oh noes") |
当需要获取调用堆栈时，则可以使用：
|
1
2
|
err := errors.New("whoops")fmt.Printf("%+v", err) |
其他建议
在上面做类型推导时，我们发现在处理一类错误时可能需要多个错误类型，这可能在某些情况下相对来说比较复杂，很多时候我们可以使用接口形式去方便处理：
|
1
2
3
4
5
6
7
8
9
|
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()} |
这样就可以提供更加方便的错误解析和处理。
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作能带来一定的帮助，如果有疑问大家可以留言交流。
原文链接：https://ipfans.github.io/2017/02/more-effective-golang-error/
