Golang Error Handling 是好的设计吗?
从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...