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())
}

运行输出:
Golang Error Handling 是好的设计吗?

4、Golang 2 草案

似乎开发者们已经习惯了try-catch-finally的用法,对于官方给出的Error Handling的设计解释并不买账,于是在Golang 2 草案中,Error Handling作为一个重大改变被提了出来,并给出了优化方案:增加checkhandle两个新关键字。
这里有两个对比示例:

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...

相关推荐