从Java、C++、PHP转过来的Gopher在遇到错误处理时都会很苦恼，与前者们的类似try/catch模式相比，Golang的检查返回值判断错误的写法显得特别繁琐。本文试图去探究下Golang中Error Handling设计的背景与思维过程，力求还原一个真实的设计权衡。
1、标准包中的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来的简洁：错误统一处理，开发者专注当前业务流程。
2、为什么是这个样子？
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.
3、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())
}
运行输出：
4、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的正式标准中，但如此好的设计值得期待。
5、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...
有疑问加站长微信联系（非本文作者）
