【GoLang】GoLang 错误处理 -- 使用异常的思路进行处理

go处理错误的另一种方式

go处理错误常见的方式是

err := funcReturningError()
if err != nil {
  // 处理错误
}

然而因为过于繁琐而饱受诟病。下文简述另一种处理错误的写法。

这种写法最初我是从标准库里看到的，代码在 https://github.com/golang/go/blob/master/src/encoding/gob/error.go 。 简言之，就是将错误用panic抛出，然后在某个边界用defer将其转为error值。这和其他用抛异常来处理错误的语言类似。 不过上述代码并不十分通用，也没有解决最开始提出的写法繁琐的问题。 受其启发，我现在用得最多的错误处理方式是这样的 https://github.com/reusee/codes/blob/master/err/err.go 。

首先是Err结构体，定义如下

type Err struct {
  Pkg, Info string
  Err error
}

Pkg用于标识抛出错误的包，Info是对错误的描述。Err用于包装另一个错误，一般是当前函数所调用的函数返回的，可以实现类似java的chained exception的机制，后面再细说。

另外有一个me函数（make error），用于包装error，实现很简单不提。

然后是ce函数（check error）

func ce(err error, info string) {
  if err != nil {
    panic(me(err, info)) } } 

这个函数检查err参数是否为nil，如果不是，则包装出一个Err结构，然后用panic抛出。 这个就是用于替代if err != nil { … }的了。

错误用panic抛出后，必须在某个边界recover，API不应该对外暴露panic，否则会和go社区整体的理念不合，自找烦恼。 负责这个的是ct函数（catch error）

func ct(err *error) {
  if p := recover(); p != nil {
    if e, ok := p.(error); ok { *err = e } else { panic(p) } } } 

因为用到了recover，所以ct只能在defer函数里调用。它首先recover()，然后看是否是error，是则将其赋值到传入的*error处，否则重新panic抛出

来看看它是如何减少代码的，以 https://blog.golang.org/errors-are-values 的一段代码为例

_, err = fd.Write(p0[a:b])
if err != nil {
  return err
}
_, err = fd.Write(p1[c:d])
if err != nil { return err } _, err = fd.Write(p2[e:f]) if err != nil { return err } 

用上述机制，可以写成

defer ct(&err)
_, err = fd.Write(p0[a:b])
ce(err, "write p0")
_, err = fd.Write(p1[c:d])
ce(err, "write p1")
_, err = fd.Write(p2[e:f])
ce(err, "write p2")

代码没有那样繁琐了。

另外还有一个好处是，因为Err包装了上一个错误，所以定位错误比较容易。例如下面程序

package main

func foo() (err error) {
    defer ct(&err)
    ce(bar(), "call bar")
    return } func bar() (err error) { defer ct(&err) ce(baz(), "call baz") return } func baz() (err error) { return me(nil, "baz") } func main() { ce(foo(), "call foo") } 

paniclog是这样的

panic: foobar: call bar
foobar: call baz
foobar: baz
...

可以看出最外层的error包含了直到最内层的信息，包括包名foobar（这里只用到一个包所以体现不出），比起直接将最内层的error往上抛，要直观得多。

最后说说这种写法的缺点。首先是不论有无错误都调用recover，调用recover又要使用defer函数，所以性能会受到影响。 另外因为没有 if 语句了，做覆盖测试的话，区分不出两种case了。 所以这种写法并不适合所有场景。需要压榨性能时不用，需要做覆盖测试时不用。 适合的场景是对性能要求不高的，对正确性要求也不高的。 我会用在经常变的应用代码，或者百几十行的小程序，或者测试代码里。 基础的包，还是好好写 if err != nil { … } 吧。

以上ct、me、ce等函数都不是public的，因为我使用时，是用代码生成工具复制出来用的，不需要public。 用的代码生成工具是 https://github.com/reusee/ccg ，可能会有另外一篇博文说说这个。

 

参考资料：

http://reusee.github.io/post/error-handling/