我不允许你只会 if err == nil ,请收下这份优雅处理错误的指南

Go 的错误异常处理,一直都是一个非常好玩的话题。

如果你习惯了 try catch 这样的语法后,会觉得处理错误真简单,然后你再来接触 Go 的错误异常,你会发现他好复杂啊,怎么到处都是 error,到处都需要处理 error。

所以如果你去一些论坛,或许喷得最多的就是这个点了。

一、Go 的约定

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

这虽然官方在这点上没有做硬性规定,但是大家也都习惯这么做,所以大家在写代码时就尽量不要去违反了哈,咱就是放第一个,咱就是玩,估计会被骂死的。

至于为啥 Go 要这样去设计处理异常,咱们这种干饭人事就不去分析了,官方怎么设计咱们就怎么遵守就好了。

二、简单错误创建

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

1、 errors

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

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

2、fmt

可能大多数同学都习惯用 fmt 去输出一些内容,同样他还能为我们创建错误。

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

相比 errors 包,fmt 还支持格式化字符串输出。

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

三、哨兵错误

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

怎么去理解呢?

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

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

拿我们常用的 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("没找到")
}

其实这样用 == 比较是有坑的,后面我们会讲到。

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

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

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

四、对错误进行编程

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

所以我们尽量避免去比较 error.Error() 输出的值,因为他正常情况下不是给我们人看的,而是给程序看的,同时方便我们调试。

所以,Go 里面的错误其实我们可以进行一系列的编程。

Go 语言中的错误定义是一个借口,只要是声明了 Error() string 这个方法,就意味着他就可以判定他是一个错误。

这是 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)
}

2、错误的API

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

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

1、Is

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

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

尽量少用,最好不用。

也少用这样的方式:

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

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

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

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

}
}

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

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

func (this *MyError) Is(target error) bool {
 log.Println("到这里来了....")
 if inputE, ok := target.(*MyError); ok {
  if inputE.Code == this.Code && inputE.Msg == this.Msg {
   return true
  }
 }
 return false
}

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

if errors.Is(e, NewMyError(404“ddd”)) {
log.Println(“是 ErrorNotFind”)
}else {
log.Println(“不是 ErrorNotFind”)
}
}

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

go run main.go 
2022/08/13 17:20:48 404-找不到内容
2022/08/13 17:20:48 到这里来了....
2022/08/13 17:20:48 不是 ErrorNotFind

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 
2022/08/13 17:30:06 最原始的错误: 404-找不到内容
2022/08/13 17:30:06 加了上下文的错误: 404-hello找不到内容

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

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

总结

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

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

其次每个人对错误的理解和处理思路方式都不太一样。

欢迎留下你对错误处理的思路和看法,就比如:

我们到底是该多使用哨兵错误,还是该少用呢?

很期待你的留言!

admin
Author: admin

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注