88.Go设计优雅的错误处理

导言

在 75.错误码设计、实现统一异常处理和封装统一返回结果 中，我们介绍了错误码的设计，包括错误码的分段式含义。本篇文章，我们将结合错误码以及错误msg介绍一下Go中优雅的错误处理是如何设计的。共有两种常见方式：

1. 哨兵错误
2. 定义结构体（至少包含code和msg)两个字段

一、Go 的约定

首先咱们需要知道 Go 语言里面有个约定，就是一个方法的返回参数，我们通常习惯的把错误当最后一个参数返回。

这虽然官方在这点上没有做硬性规定，但是大家也都习惯这么做，至于为啥 Go 要这样去设计处理异常，想必是约定俗成，让大家有统一的写法，所以官方怎么设计咱们就怎么遵守就好了。

二、简单错误创建

Go 的标准库里面为我们提供了两种使用字符串快速创建错误的方式。

1、 errors.New()

我们可以使用errors包的 New 方法，传入一个字符串快速地创建。

var e error
e = errors.New("我是错误")

2、fmt.Errorf()

可能大多数同学都习惯用 fmt 去拼装一些内容，然后创建错误，省去了用fmt.Sprintf拼装字符串，然后再调用errors.New()，而是拼装msg和创建错误一步到位了。

var e error
e = fmt.Errorf("你好，%s", "我还是错误")

从这个角度可以看到，其实错误对 Go 语言来说，其实就是一段字符串。

三、哨兵错误

接下来我们分享 Go 中最常用的设计 error 的方式，那就是哨兵模式。

哨兵错误是计算机编程中使用一个特定的值来表示不可能进一步处理的做法，通常在Go语言编程中使用，用于在包内先定义一些错误，然后在包外进行错误值的判断。哨兵错误的注意事项在Go的官方博客中也提到，哨兵错误是包级别的，可以用于在包外进行错误值的判断，但这样会造成包和包之间的依赖，如果哨兵错误做了修改，那么之前依赖该错误的所有包都需要更改。

怎么去理解呢？

就像童话故事里一座城堡，在城堡的一些关卡，总会安排各种各样的哨兵，他们不同哨兵负责的事不同。

所以我们通常会在一个包里面设置一些标志性的错误，方便调用者对错误做更好的处理。

拿我们常用的 GORM 这个库吧，我们在查询某条数据的时候，如果没找到这条数据，不知道你是怎么判断的。

其实官方为我们提供了错误哨兵，在源码 github.com/jinzhu/gorm/errors.go中：

var (
 // ErrRecordNotFound returns a "record not found error". Occurs only when attempting to query the database with a struct; querying with a slice won't return this error
 ErrRecordNotFound = errors.New("record not found")
 // ErrInvalidSQL occurs when you attempt a query with invalid SQL
 ErrInvalidSQL = errors.New("invalid SQL")
 // ErrInvalidTransaction occurs when you are trying to `Commit` or `Rollback`
 ErrInvalidTransaction = errors.New("no valid transaction")
 // ErrCantStartTransaction can't start transaction when you are trying to start one with `Begin`
 ErrCantStartTransaction = errors.New("can't start transaction")
 // ErrUnaddressable unaddressable value
 ErrUnaddressable = errors.New("using unaddressable value")
)

所以我们就可以直接通过返回的 error 来判断是不是没找到数据，伪代码如下：

g,_ := gorm.Open()
e = g.Find().Error
if e == gorm.ErrRecordNotFound {
 fmt.Println("没找到")
}

其实这样用 == 比较是有坑的，比如包内ErrRecordNotFound = errors.New("record not found")错误被gorm包的开发着删除了，这里的代码一升级包依赖，就会编译报错了，不过删除已经定义的错误这种情况一般不会出现。可以用Is解决这种情况，后面会介绍。

所以如果我们在写我们的模块的时候，也可以这样去设计我们的错误。

虽然这种设计模式网上也有很多人说不好，因为他建立起了两个包之间的依赖，说人话就是，如果我们要比较错误，就必须导入错误所在的包。

反正任何设计都会有人说好有人说坏，大家理智看到就好了。

四、对错误进行编程

我们需要时刻记住，Go 语言中错误其实就是一串字符串。

我们应该尽量避免去比较 error.Error() 输出的值，因为不同协作者写代码时返回的字符串（错误提示信息）很可能是不一样的。

Go 语言中的错误定义是一个接口，只要是声明了 Error() string 这个方法，就意味着它实现了Error接口。

这是 Go 中的错误定义源码：

// The error built-in interface type is the conventional interface for
// representing an error condition, with the nil value representing no error.
type error interface {
 Error() string
}

如果官方的错误，并不能满足你的需求，咱们也可以自定义。

1、优雅的错误处理设计

我们先来使用常量去创建自定义错误吧：

type MyError string

func (this MyError) Error() string {
 return string(this)
}

这样我们就创建好我们的自定义错误了，使用下：

func main() {
 var e error
 e = MyError("hello")
 fmt.Println(e)
}

当然我们可以把 string 换成 struct ，同时加入很多我们自定义的属性：工作中非常常用

type MyError struct {
 Code int
 Msg string
}

func NewMyError(code int, msg string) *MyError {
 return &MyError{Code: code, Msg: msg}
}

func (this MyError) Error() string {
 return fmt.Sprintf("%d-%s",this.Code, this.Msg)
}

// FindUser 模拟下我们的业务方法
func FindUser() error {
 return NewMyError(404, "找不到内容")
}

func main() {
 var e error
 e = FindUser()
 fmt.Println(e)
}

当然，实际工作中，一般还会用metrics打点记录错误情况，方便后续进行监控报警，而业务上有一些预期内的错误或者稳定性不需要处理的错误，我们希望不要报警。一方面可以在报警规则中过滤，另一方面我们其实可以在错误设计和上报的时候就打点，标记错误是否为稳定性错误。如下：

// 错误码枚举
type ErrorCodeEnum int64

const (
 // 定义可预见的异常
  UserNotFound ErrCodeEnum = 10001
  PasswrodErr ErrCodeEnum = 10002
)

type BizErr struct {
	code     ErrCodeEnum  
	msg      string
	isStable bool   // 是否是稳定性错误
}

func NewBizErr(code ErrCodeEnum, msg string) *OpStrategyErr {
	return &OpStrategyErr{
		code:     code,
		msg:      msg,
		isStable: ErrorCodeIsStable(code),
	}
}

func (e *OpStrategyErr) Code() strategy_error.OpStrategyErrCode {
	return e.code
}

func (e *OpStrategyErr) Error() string {
	return e.msg
}

func (e *OpStrategyErr) IsStable() bool {
	return e.isStable
}

func ErrorCodeIsStable(errCode ErrCodeEnum) bool {
	errCodeStr := strconv.FormatInt(int64(errCode), 10)
	if len(errCodeStr) < 4 {
		return false
	}
	// 假设以1000开头认为是稳定性错误
	if errCodeStr[:4] == "1000" {
		return true
	}
	return false
}

func IsErrNil(err error) bool {
	if err == nil {
		return true
	}
	vi := reflect.ValueOf(err)
	if vi.Kind() == reflect.Ptr {
		return vi.IsNil()
	}
	return false
}

2、与错误有关的的API

最后我们来说说 Go 语言中与错误有关的 API，到目前为止，我们面对错误除了输出外，就是使用 == 对错误进行哨兵比较，但是这样未必准确。

所以官方在错误的基础上，又扩展了几个 API。

1、Is

我们面对错误，尽量不要使用这样的方式去比较：

// 尽量少用
if e.Error() == "404-找不到内容" {
}

尽量少用，最好不用。

也少用这样的方式：

type MyError struct {
 Code int
 Msg string
}

func NewMyError(code int, msg string) *MyError {
 return &MyError{Code: code, Msg: msg}
}

func (this MyError) Error() string {
 return fmt.Sprintf("%d-%s",this.Code, this.Msg)
}

var ErrorNotFind = NewMyError(404, "找不到内容")

// FindUser 模拟下我们的业务方法
func FindUser() error {
 return ErrorNotFind
}

func main() {
 var e error
 e = FindUser()
 log.Println(e)

 // 尽量少用
 if e == ErrorNotFind {

 }
}

目前我们的错误结构体还是非常简单的，如果我们的结构体里面的属性再多几个，很可能就会出现牛头对马嘴情况。

注意：Go 中 struct是值类型，所以==比较，是比较里面每个字段的值是否相等

所以官方为我们提供了 Is 方法的 API，他默认使用==将特定的错误与错误链中的错误进行比较，如果不一样，就会去调用错误实现的Is方法进行比较。

func (this *MyError) Is(target error) bool {
 log.Println("到这里来了....")
 if inputE, ok := target.(*MyError); ok {
   // 注意：== 比较就是比较struct的各字段是否相等，而我们这里用Is，只想比较错误码是否相等
  //if inputE.Code == this.Code && inputE.Msg == this.Msg {
  //   return true
  //}
  if inputE.Code == this.Code {
   return true
  }
 }
 return false
}

func main() {
 var e error
 e = FindUser()
 log.Println(e)

 // 注意我们定义的时候是var ErrorNotFind = NewMyError(404, "找不到内容")
 // 但这里传递的msg是ddd，所以用e==NewMyError(404, "ddd")会是false
 if errors.Is(e, NewMyError(404, "ddd")) {
  log.Println("是 ErrorNotFind")
 }else {
  log.Println("不是 ErrorNotFind")
 }
}

首先我们先去实现下 Is 这个方法，随后我们使用 errors.Is 进行比较，你会看到控制台输出了：

$ go run main.go 
2024/02/07 14:20:48 404-找不到内容
2024/02/07 14:20:48 到这里来了....
2024/02/07 14:20:48 是 ErrorNotFind

从输出结果不难看出，errors.Is也是先用==进行了比较，发现不相等后，又调用了MyError的Is方法，只比较错误码是否一致，是相等的。

2、Unwrap

这是一个不大常用的API，标准库里面fmt.Errorf就是一个非常典型的使用案例。

场景是什么呢？

我们通常在错误异常的时候，会有给错误加上一些上下文的需求，那在哪里加呢？

就是错误的 Unwrap 方法里面：

func (this *MyError) Unwrap() error {
 this.Msg = "hello" + this.Msg
 return this
}

func main() {
 var e error
 e = FindUser()
 log.Println("最原始的错误：", e)
 wE := errors.Unwrap(e)
 log.Println("加了上下文的错误：", wE)
}

然后看下我们的输出结果：

$ go run main.go 
2024/02/07 14:30:06 最原始的错误： 404-找不到内容
2024/02/07 14:30:06 加了上下文的错误： 404-hello找不到内容

你会发现，errors.Unwrap 后的错误调用了我们自定义错误的 Unwrap 方法，在我们的 msg 前面加了 hello。

对错误进行编程最常用的两个API就是这两个了，还有一些不大常用的比如 As，大家感兴趣的可以自行去翻阅下资料。

五、总结

Go 的错误处理和其他语言不太一样，如果遵守错误处理的规范，不对错误进行隐藏，写出来的代码一般都是比较健壮的。

于是就难免会出现一个包里面，特别多的错误处理代码，这就是时间和空间的博弈，就看 Go 语言的领路人如何取舍了。

其次每个人对错误的理解和处理思路方式都不太一样。就比如：我们到底是该多使用哨兵错误，还是该少用呢？

但是最通用的还是哨兵错误以及自定义结构体作为错误。