1. 两种观点

但 Go 在错误处理方面体现出的这种与如今主流语言的格格不入，让很多来自这些主流语言的 Go 初学者感到困惑：Go 代码中反复出现了太多的且方法单一的错误检查if err != nil。比如下面这段摘自“Go2 错误处理概述”中的代码：

func CopyFile(src, dst string) error {
    r, err := os.Open(src)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    defer r.Close()
    w, err := os.Create(dst)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    if _, err := io.Copy(w, r); err != nil {
        w.Close()
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    if err := w.Close(); err != nil {
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

下面是 Go 团队在错误处理改善方面的工作梳理：

2018 年 8 月

2019 年 6 月

原生 Go 错误检查-try 设计草案
tryhard 项目：try 设计草案的实验性实现

2. 我们该怎么办？尽量去优化

另外一名 Go 团队核心开发人员Marcel van Lohuizen也对if err != nil的重复出现情况也进行了研究。他发现代码所在栈帧越低(越接近与 main 函数栈帧)，if err != nil就越不常见；反之，代码在栈中的位置越高（更接近于网络 I/O 操作或操作系统 API 调用），if err != nil出现的就越普遍，正如上面CopyFile那个例子中的情况：

3. 优化思路

改善代码的视觉呈现：这个优化方法就好比给开发人员施加了某种“障眼法”，使得错误处理代码在开发者眼中的视觉呈现更为“优雅”。上面提到的 Go2 关于改善错误处理的几个技术草案本质上就是提供一种改善代码视觉呈现的语法糖。

比如：如果待优化的代码像下面这样：

func SomeFunc() error {
    err := doStuff1()
    if err != nil {
        //handle error...
    }
    err = doStuff2()
    if err != nil {
        //handle error...
    }
    err = doStuff3()
    if err != nil {
        //handle error...
    }
}

那么经由try技术草案优化后的代码将大致变成这样(由于 try 提案被否决，因此我们无法真实实现下面这样的错误处理)：

func SomeFunc() error {
    defer func() {
        if err != nil {
            // handle error...
        }
    }()
    try(doStuff1())
    try(doStuff2())
    try(doStuff3())
}

降低 if err != nil 重复的数量：如果觉得if err != nil重复的次数过多，我们可以降低其出现次数，这其实是将该问题转换为降低函数/方法的复杂度了。

一个函数/方法内部出现多少个if err != nil才需要我们去优化和消除这种代码重复呢？这显然没有标准可言。我这里想到了一个粗略的评估方法：利用圈复杂度(Cyclomatic complexity)。圈复杂度是一种代码复杂度的衡量标准，我们常用它来衡量一个模块判定结构的复杂程度。圈复杂度大说明程序代码可能质量低且难于测试和维护，根据经验，程序的可能错误和高的圈复杂度有着很大关系。

圈复杂度可以通过程序控制流图计算，公式为：V(G) = e + 2 - n。其中：e 为控制流图中边的数量；n 为控制流图中节点的数量(包括起点和终点；所有终点只计算一次，多个 return 和 throw 算作一个节点)。下面是不同数量的 if 语句对应的不同圈复杂度：

我们看到三组 if 语句（不带 else）的圈复杂度已经达到了 4，两组 if 语句的圈复杂度为 3。因此这里给出一个建议值：对圈复杂度为 4 或 4 以上的模块代码进行重构优化，即如果一个函数/方法中的if err != nil数量为 3 个或 3 个以上，我们将尝试对其进行代码优化，以尝试减少或消除过多的if err != nil代码片段。当然这个建议值对于那些有代码洁癖的 gopher 来说可以全不作数_。

现实中的真实优化实施更多是上述两个方向的结合，这里用一幅四象限图来直观展示一下可能的优化思路：

1) 视觉扁平化

Go 提供了将触发错误处理的语句与错误处理代码放在一行的支持，比如上面的 SomeFunc 函数，我们可以将之等价重写为下面代码：

func SomeFunc() error {
    if err := doStuff1(); err != nil { // handle error... }
    if err := doStuff2(); err != nil { // handle error... }
    if err := doStuff3(); err != nil { // handle error... }
}

不过这种优化显然是有约束的，如果错误处理分支的语句不是简单的return err，而是复杂如下面代码中这样：

if _, err = io.Copy(w, r); err != nil {
    return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

那么”扁平化”会导致代码行过长，反倒降低了视觉呈现的“优雅度”。另外如果你使用goimports或gofmt工具对代码进行自动格式化，那么这些格式化工具会自动展开上述代码，这会让你困惑不已。

2) 重构：减少if err != nil的重复次数

我们沿着降低复杂度的方向对待优化代码进行重构，以减少if err != nil代码片段的重复次数。我们以上面的CopyFile为优化对象。原 CopyFile 函数有 4 个重复出现的if err != nil代码段，这里我们将其减至 2 个。下面是一种优化方案的代码实现：

// go-if-error-check-optimize-1.go
func openBoth(src, dst string) (*os.File, *os.File, error) {
    var r, w *os.File
    var err error
    if r, err = os.Open(src); err != nil {
        return nil, nil, fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    if w, err = os.Create(dst); err != nil {
        r.Close()
        return nil, nil, fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    return r, w, nil
}
func CopyFile(src, dst string) error {
    var err error
    var r, w *os.File
    if r, w, err = openBoth(src, dst); err != nil {
        return err
    }
    defer func() {
        r.Close()
        w.Close()
        if err != nil {
            os.Remove(dst)
        }
    }()
    if _, err = io.Copy(w, r); err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    return nil
}

感觉是强行减少, 我比较在意返回参数的个数.

3) check/handle 风格化

上面的位于第四象限的重构之法虽然减少了if err != nil代码片段的重复次数，但其视觉呈现依旧欠佳。Go2 的check/handle 技术草案的思路给了我们一些启发，我们可利用 panic 和 recover 封装一套跳转机制，模拟实现一套 check/handle 机制，在降低复杂度的同时，也能在视觉呈现上有所改善。我们仍然以CopyFile为例进行优化：

// go-if-error-check-optimize-2.go
func check(err error) {
    if err != nil {
        panic(err)
    }
}
func CopyFile(src, dst string) (err error) {
    var r, w *os.File
    // error handler
    defer func() {
        if r != nil {
            r.Close()
        }
        if w != nil {
            w.Close()
        }
        if e := recover(); e != nil {
            if w != nil {
                os.Remove(dst)
            }
            err = fmt.Errorf("copy %s %s: %v", src, dst, err)
        }
    }()
    r, err = os.Open(src)
    check(err)
    w, err = os.Create(dst)
    check(err)
    _, err = io.Copy(w, r)
    check(err)
    return nil
}

不过这一优化方案也具有一定约束，比如：函数必须使用具名的 error 返回值、defer 性能(在 Go 1.14 版本中，与不使用 defer 的性能差异微乎其微，可忽略不计）、panic 和 recover 的性能等。尤其是 panic 和 recover 的性能要比正常函数返回的性能相差好多，下面是一个简单的性能基准对比测试：

// panic_recover_performance_test.go 
package main
import (
    "errors"
    "testing"
)
func check(err error) {
    if err != nil {
        panic(err)
    }
}
func FooWithoutDefer() error {
    return errors.New("foo demo error")
}
func FooWithDefer() (err error) {
    defer func() {
        err = errors.New("foo demo error")
    }()
    return
}
func FooWithPanicAndRecover() (err error) {
    // error handler
    defer func() {
        if e := recover(); e != nil {
            err = errors.New("foowithpanic demo error")
        }
    }()
    check(FooWithoutDefer())
    return nil
}
func FooWithoutPanicAndRecover() error {
    return FooWithDefer()
}
func BenchmarkFuncWithoutPanicAndRecover(b *testing.B) {
    for i := 0; i < b.N; i++ {
        FooWithoutPanicAndRecover()
    }
}
func BenchmarkFuncWithPanicAndRecover(b *testing.B) {
    for i := 0; i < b.N; i++ {
        FooWithPanicAndRecover()
    }
}

运行上述性能基准测试：

$ go test -bench . panic_recover_performance_test.go
goos: darwin
goarch: amd64
BenchmarkFuncWithoutPanicAndRecover-8       39020437            28.8 ns/op
BenchmarkFuncWithPanicAndRecover-8           4442336           271 ns/op
PASS
ok      command-line-arguments    2.639s

4) 封装：内置 error 状态

在 Go 语言之父 Rob Pike 的”Errors are values”一文中，Rob Pike 为我们呈现了 Go 标准库中使用了避免if err != nil反复出现的一种代码设计思路，bufio 包的 Writer 就是使用了这个思路实现的，因此它可以可以像下面这样使用：

b := bufio.NewWriter(fd)
b.Write(p0[a:b])
b.Write(p1[c:d])
b.Write(p2[e:f])
// and so on
if b.Flush() != nil {
        return b.Flush()
    }
}

我们看到上述代码中并没有判断三个 b.Write 的返回错误值，错误处理放在哪里了呢？我们打开一下$GOROOT/src/bufio/bufio.go，我们看到下面代码：

// $GOROOT/src/bufio/bufio.go
type Writer struct {
    err error
    buf []byte
    n   int
    wr  io.Writer
}
func (b *Writer) Write(p []byte) (nn int, err error) {
    for len(p) > b.Available() && b.err == nil {
        ... ...
    }
    if b.err != nil {
        return nn, b.err
    }
    ......
    return nn, nil
}

我们可以看到，错误状态被封装在 bufio.Writer 结构的内部了，Writer 定义了一个 err 字段作为一个内部错误状态值，它与 Writer 的实例绑定在了一起，并且在每次 Write 入口判断是否为 nil。一旦不为 nil，Write 其实什么都没做就返回了。

先一股脑写代码, 最后只检查一次 err 的状态.

这种方法显然是消除if err != nil代码片段重复出现的理想方法。我们还以CopyFile为例，看看使用这种“内置 error 状态”的新封装方法后，我们能得到什么样的代码：

// go-if-error-check-optimize-3.go
package main
import (
    "fmt"
    "io"
    "os"
)
type FileCopier struct {
    w   *os.File
    r   *os.File
    err error
}
func (f *FileCopier) open(path string) (*os.File, error) {
    if f.err != nil {
        return nil, f.err
    }
    h, err := os.Open(path)
    if err != nil {
        f.err = err
        return nil, err
    }
    return h, nil
}
func (f *FileCopier) openSrc(path string) {
    if f.err != nil {
        return
    }
    f.r, f.err = f.open(path)
    return
}
func (f *FileCopier) createDst(path string) {
    if f.err != nil {
        return
    }
    f.w, f.err = os.Create(path)
    return
}
func (f *FileCopier) copy() {
    if f.err != nil {
        return
    }
    if _, err := io.Copy(f.w, f.r); err != nil {
        f.err = err
    }
}
func (f *FileCopier) CopyFile(src, dst string) error {
    if f.err != nil {
        return f.err
    }
    defer func() {
        if f.r != nil {
            f.r.Close()
        }
        if f.w != nil {
            f.w.Close()
        }
        if f.err != nil {
            if f.w != nil {
                os.Remove(dst)
            }
        }
    }()
    // 流畅的 Go!
    f.openSrc(src)
    f.createDst(dst)
    f.copy()
    return f.err
}
func main() {
    var fc FileCopier
    err := fc.CopyFile("foo.txt", "bar.txt")
    if err != nil {
        fmt.Println("copy file error:", err)
        return
    }
    fmt.Println("copy file ok")
}

改善Go语言编程质量的50个有效实践

31 if err != nil 重复太多可以这么办