Golang Error Handling 是好的设计吗？

从Java、C++、PHP转过来的Gopher在遇到错误处理时都会很苦恼，与前者们的相似try/catch模式相比，Golang的检查返回值判断错误的写法显得特别繁琐。本文试图去探究下Golang中Error Handling设计的背景与思惟过程，力求还原一个真实的设计权衡。

一、标准包中的Error Handling

Golang标准包提供的Error Handling功能是经过error这个interface实现的。

type error interface {
    Error() string
}

因此自定义一个error类型很简单，只要实现Error方法便可：

// errorString is a trivial implementation of error.
type errorString struct {
    s string
}

func (e *errorString) Error() string {
    return e.s
}

那么如何处理错误呢？
官方推荐使用相似于C语言的，检查返回值的方式（if err != nil），例如：

func readfile(path string) error {
    err := openfile(path)
    if err != nil {
        return fmt.Errorf("cannot open file: %v", err)
    }
    //...
}

以上可能还看不出问题，好比下面这样：

func DoSomething() (*C, error) {
   var err error
   var a string
   a, err =DoA()
   if err == nil {
      var b string
      b, err = DoB(a)
      if err == nil {
         var c string
         c, err = DoC(b)
         if err == nil {
            return c, nil
         }
      }
   }
   return nil, err
}

每次调用一个函数都须要作一次错误检查，这使得代码写起来十分繁琐，而不像其余编程语言中的try/catch来的简洁：错误统一处理，开发者专一当前业务流程。

二、为何是这个样子？

Golang的错误处理模式受到了许多批评的声音，因而Rob Pike不得不在官网刊文解释，并声明『Errors are values』:Values can be programmed, and since errors are values, errors can be programmed.，即开发者能够自定义error类型，优雅地设计符合自身业务流程的错误处理方式。

但同时他再次强调到：无论怎么设计，在程序中检查暴露出来的错误都是相当重要的。
一直到文章最后，Rob Pike都没有解释为何要这么设计，而是在阐述如何优雅地使用Error Handling。

继续搜索之，官方的FAQ道出了设计背后考虑：We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. 即官方认为将异常耦合到控制结构（就像尝试try-catch-finally习惯用法同样）会致使复杂的代码，并鼓励开发者去显示地检查错误，这样程序流程不会被打断。这也是为何Golang会提供多值返回的缘由之一。虽然与其余编程语言不一样， 但规范化的错误类型，加上Golang的其余特性（如error可编程），使错误处理变得方便。

总结起来，Error Handling的设计初衷是拿编码的冗余性换取了逻辑的简单性，这即是其中的tradeoff，正如 Go proverbs所言：Clear is better than clever.

三、pkg包中的Error Handling

使用错误处理的姿式每每不止一种，标准库里经过的Error接口只够知足通常简单的场景，对于某些须要了解错误细节（如判断错误是网络中断仍是返回值格式问题）以及当前执行栈的场景，则须要对Error接口的进一步封装，目前比较推崇的是github.com/pkg/errors包。

它除了输出调用层级上每一级错误内容以外，还能够打印出发生错误的文件名与所在行号，这对于定位Bug很是有帮助。
使用方法也很简单，能够看下面一个例子：

package main

import (
    "fmt"

    "github.com/pkg/errors"
)

func A() error {
    return errors.New("NullPointerException")
}

func B() error {
    return A()
}

func main() {
    fmt.Printf("Error: %+v", B())
}

运行输出：

四、Golang 2 草案

彷佛开发者们已经习惯了try-catch-finally的用法，对于官方给出的Error Handling的设计解释并不买帐，因而在Golang 2 草案中，Error Handling做为一个重大改变被提了出来，并给出了优化方案：增长check与handle两个新关键字。
这里有两个对比示例：

Go 1

type Parsed struct { ... }

func ParseJson(name string) (Parsed, error) {

    // Open the file
    f, err := os.Open(name)
    if err != nil {
        return fmt.Errorf("parsing json: %s %v", name, err)
    }
    defer f.Close()

    // Parse json into p
    var p Parsed
    err = json.NewDecoder(f).Decode(&p)
    if err != nil {
        return fmt.Errorf("parsing json: %s %v", name, err)
    }

    return p
}

Go 2

type Parsed struct { ... }

func ParseJson(name string) (Parsed, error) {
    handle err {
        return fmt.Errorf("parsing json: %s %v", name, err)
    }

    // Open the file
    f := check os.Open(name)
    defer f.Close()

    // Parse json into p
    var p Parsed
    check json.NewDecoder(f).Decode(&p)

    return p
}

对比能够发现：增长了check与hanle关键字以后，总体的代码逻辑变得更加简洁，错误能够统一在handle处获得处理，相似于try/catch.

• check：负责显示地检查错误（标记）
• handle：定义错误处理逻辑，一旦check到指定错误，便会进入相应的错误处理逻辑。

固然，做为2.0的草案，并不必定会最终归入Golang2的正式标准中，但如此好的设计值得期待。

五、References

https://blog.golang.org/error...
https://dave.cheney.net/paste...
https://blog.golang.org/error...
https://golang.org/doc/faq#ex...
https://medium.com/@hussachai...
https://blog.golang.org/go2draft
https://go.googlesource.com/p...
https://dev.to/deanveloper/go...