Go中err那些事
1. 技术背景
大家在用Go语言开发项目的过程中，我相信有一个比较痛的点，那就是频繁处理err。不怕err多，就怕err返回了也不知道是因为什么报错返回的，更加无奈，因为对你排查问题一丁点帮助都没有。那这篇文章我们就来聊聊Go中err那些事，帮你揭开谜底。
2. 基调
- Go函数支持多返回值
- Errors are values（很重要，而且必须认可这点）
3. 错误处理例子
retVal, err := func() if err != nil { return err } //如果想忽略错误 可以这样写 retVal, _ := func()
4. 优点
- 1.函数接口语义明确清晰，参数基本上都是入参，而返回参数把结果和错误分离；
- 2.错误参数如果要忽略，也需要显式地忽略 _ ；
- 3.返回的error是个接口 Error() string，所以可以扩展自定义的错误处理；
- 4.如果一个函数返回了多个不同类型的error，则可以通过断言针对不同类型的错误分别做处理；
5. 缺点
1. 我们会有大量的代码来判断if err != nil
- 解决方案就是：不妨试试函数式编程、闭包、结构体封装等方式，但这不是必须的，因为Go原生sdk中也有大量的这种判断。
2. 无法清晰知道err是什么
比如当返回err是record not found、invalid params怎么快速定位是哪个地方报的错？因为它没有给你更多信息让你足够了解到底是哪里报错，因为什么报错，所以一般我们都会包装错误。
- 解决方案就是：我们通常需要包装一下错误，而不是干巴巴地把err给返到上层，我们需要把一些执行上下文加入，初衷是方便快速定位排查问题。具体怎么做：
- 用fmt.Errorf
fmt.Errorf("excection something failed: %v", err)
- 用结构体
type withMessage struct { cause error msg string } func (w *withMessage) Error() string { return w.msg + ": " + w.cause.Error() }
- errors包
github.com/pkg/errors
- Go 1.13之后Wrapping errors with %w
// Wrapping errors with %w if err != nil { // Return an error which unwraps to err. return fmt.Errorf("decompress %v: %w", name, err) } // Unwrap returns the result of calling the Unwrap method on err, if err's // type contains an Unwrap method returning error. // Otherwise, Unwrap returns nil. func Unwrap(err error) error { u, ok := err.(interface { Unwrap() error }) if !ok { return nil } return u.Unwrap() } // Examining errors with Is and As // The errors.Is function compares an error to a value. // Similar to: // if err == ErrNotFound { … } if errors.Is(err, ErrNotFound) { // something wasn't found } // The As function tests whether an error is a specific type. // Similar to: // if e, ok := err.(*QueryError); ok { … } var e *QueryError // Note: *QueryError is the type of the error. if errors.As(err, &e) { // err is a *QueryError, and e is set to the error's value }
- 定义err变量
var ( ErrInvalidParam = errors.New("invalid param") ) if err != nil && err == ErrInvalidParam { //... } //如果有太多这种自定义err想要一次性处理，那么可以这样写： if err != nil { switch err { case ErrInvalidParam: //8888 return case ErrInvalidConnection: //9999 return default: //7777 return } } //但是这样也有小问题，当有一天error在传递的过程中，有可能会被别人包装，以携带更多的堆栈信息，比如下面这样： if err != nil { // 在包装错误的时候，这里格式化错误要使用 %w return fmt.Errorf("excection something failed, origin error: %w",err) } //假设上面被包装的错误是ErrInvalidParam，那么在调用的地方判断错误，就不能使用下面的代码： if err != nil && err == ErrInvalidParam { } //而是得有errors包中的Is函数来判断被包装的error中是否有预期的error: if errors.Is(err, ErrInvalidParam) { } //这个`Is`函数，还有另外一个`As`函数大家可以看下序号*【4】*；
6. 处理规范
- 在函数中，通常error是最后一个返回参数，程序通过error变量判定错误类别并处理。
- 错误可以使用 ‘_’ 忽略，但是严格意义上来说不能忽略；
- 原始错误不可以被隐藏，无论是否包装错误，错误文本都将相同；
- 如发生错误，应避免继续业务逻辑执行（失败重试等特殊场景除外）；
- 对外接口一律返回 error 而不是 panic ;
- ’父‘协程无法捕获’子‘协程内的Panic，所以每个协程应自行recover();
- 出错后需要及时清理资源；
- 错误并不会在第一时间被处理掉，更多的是被包装，再次向上抛出，添加上下文及调用栈信息，方便开发者快速定位问题；
- 建议在某一统一地方（表现层）进行处理（记录日志、告警机器人等）
- 建议使用%w包装错误，用Is()或As()判断错误是否属于某一具体错误或某一具体类型；
- 不要向服务外部公开内部错误细节；
- 尽量不要在函数返回值直接对变量进行声明；
7. 小结
如果细说下来还有非常多的知识点需要挖掘，但是常用的比较基础的处理err的解决方案无非就这几种，所以大家下来掌握这块知识的时候务必了解Go中基础error的特性再来看这篇文章，否则像我们文中提到的自定义错误类型实现你就很懵了。
参考：
