导语 |错误处理一直以一是编程必需要面对的问题,错误处理如果做的好的话,代码的稳定性会很好。不同的语言有不同的出现处理的方式。Go语言也一样,在本篇文章中,我们来讨论一下Go语言的错误处理方式。

一、错误与异常

(一)Error

错误是程序中可能出现的问题,比如连接数据库失败,连接网络失败等,在程序设计中,错误处理是业务的一部分。

Go内建一个error接口类型作为go的错误标准处理

http://golang.org/pkg/builtin/#error

// 接口定义type error interface { Error string}

http://golang.org/src/pkg/errors/errors.go

// 实现func New(text string) error { return &errorString{text}}type errorString struct { s string}func (e *errorString) Error string { return e.s}

(二)Exception

异常是指在不该出现问题的地方出现问题,是预料之外的,比如空指针引用,下标越界,向空map添加键值等。

(三)panic

对于真正意外的情况,那些表示不可恢复的程序错误,不可恢复才使用panic。对于其他的错误情况,我们应该是期望使用error来进行判定。

go源代码很多地方写panic, 但是工程实践业务代码不要主动写panic,理论上panic只存在于server启动阶段,比如config文件解析失败,端口监听失败等等,所有业务逻辑禁止主动panic,所有异步的goroutine都要用recover去兜底处理。

(四)总结

理解了错误和异常的真正含义,我们就能理解Go的错误和异常处理的设计意图。传统的try...catch...结构,很容易让开发人员把错误和异常混为一谈,甚至把业务错误处理的一部分当做异常来处理,于是你会在程序中看到一大堆的catch...

Go开发团队认为错误应该明确地当成业务的一部分,任何可以预见的问题都需要做错误处理,于是在Go代码中,任何调用者在接收函数返回值的同时也需要对错误进行处理,以防遗漏任何运行时可能的错误。

异常则是意料之外的,甚至你认为在编码中不可能发生的,Go遇到异常会自动触发panic(恐慌),触发panic程序会自动退出。除了程序自动触发异常,一些你认为不可允许的情况你也可以手动触发异常。

另外,在Go中除了触发异常,还可以终止异常并可选的对异常进行错误处理,也就是说,错误和异常是可以相互转换的。

二、Go处理错误的三种方式

(一)经典Go逻辑

直观的返回error:

type ZooTour interface { Enter error VisitPanda(panda *Panda) error Leave error}// 分步处理,每个步骤可以针对具体返回结果进行处理func Tour(t ZooTour1, panda *Panda) error { if err := t.Enter; err != nil { return errors.WithMessage(err, "Enter failed.") } if err := t.VisitPanda; err != nil { return errors.WithMessage(err, "VisitPanda failed.") } // ... return nil}

(二)屏蔽过程中的error的处理

将error保存到对象内部,处理逻辑交给每个方法,本质上仍是顺序执行。标准库的bufio、database/sql包中的Rows等都是这样实现的,有兴趣可以去看下源码:

type ZooTour interface { Enter error VisitPanda(panda *Panda) Error Leave error Err error}func Tour(t ZooTour, panda *Panda) error { t.Enter t.VisitPanda(panda) t.Leave // 集中编写业务逻辑代码,最后统一处理error if err := t.Err; err != nil { return errors.WithMessage(err, "ZooTour failed") } return nil}

(三)利用函数式编程延迟运行

分离关注点-遍历访问用数据结构定义运行顺序,根据场景选择,如顺序、逆序、二叉树树遍历等。运行逻辑将代码的控制流逻辑抽离,灵活调整。kubernetes中的visitor对此就有很多种扩展方式,分离了数据和行为,有兴趣可以去扩展阅读:

type Walker interface { Next MyFunc}type SliceWalker struct { index int funs MyFunc} func NewEnterFunc MyFunc { return func(t ZooTour) error { return t.Enter }}func BreakOnError(t ZooTour, walker Walker) error { for { f := walker.Next if f == nil { break } if err := f(t); err := nil { // 遇到错误break或者continue继续执行 } }}

(四)三种方式对比

上面这三个例子,是Go项目处理错误使用频率最高的三种方式,也可以应用在error以外的处理逻辑。

三、分层下的Error Handling

(一)一个常见的三层调用

在工程实践中,以一个常见的三层架构(dao->service->controller)为例,我们常见的错误处理方式大致如下:

// controllerif err := mode.ParamCheck(param); err != nil { log.Errorf("param=% v", param) return errs.ErrInvalidParam}return mode.ListTestName("")// service_, err := Dao.GetTestName(ctx, settleId) if err != nil { log.Errorf("GetTestName failed. err: %v", err) return errs.ErrDatabase}// daoif err != nil { log.Errorf("GetTestDao failed. uery: %s error(%v)", sql, err)}

(二)问题总结(三)Wrap erros

Go相关的错误处理方法很多,但大多为过渡方案,这里就不一一分析了(类似github.com/juju/errors库,有兴趣可以了解)。这里我以github.com/pkg/errors为例,这个也是官方Proposal的重点参考对象。

  1. 错误要被日志记录;

  2. 应用程序处理错误,保证100%完整性;

  3. 之后不再报告当前错误(错误只被处理一次)。

github.com/pkg/errors包主要包含以下几个方法,如果我们要新生成一个错误,可以使用New函数,生成的错误,自带调用堆栈信息。如果有一个现成的error ,我们需要对他进行再次包装处理,这时候有三个函数可以选择(WithMessage/WithStack/Wrapf)。其次,如果需要对源错误类型进行自定义判断可以使用Cause,可以获得最根本的错误原因。

// 新生成一个错误, 带堆栈信息func New(message string) error// 只附加新的信息func WithMessage(err error, message string) error// 只附加调用堆栈信息func WithStack(err error) error// 同时附加堆栈和信息func Wrapf(err error, format string, args ...interface{}) error// 获得最根本的错误原因func Cause(err error) error

以常见的一个三层架构为例:

go程序运行环境配置(3种方式GoError处理最佳实践)(1)

if err != nil { if errors.Is(err, sql.ErrNoRows) { return nil, errors.Wrapf(ierror.ErrNotFound, "query:%s", query) } return nil, errors.Wrapf(ierror.ErrDatabase, "query: %s error(%v)", query, err) }

bills, err := a.Dao.GetName(ctx, param) if err != nil { return result, errors.WithMessage(err, "GetName failed") }

// 请求响应组装func (Format) Handle(next ihttp.MiddleFunc) ihttp.MiddleFunc { return func(ctx context.Context, req *http.Request, rsp *ihttp.Response) error { format := &format{Time: time.Now.Unix} err := next(ctx, req, rsp) format.Data = rsp.Data if err != nil { format.Code, format.Msg = errCodes(ctx, err) } rsp.Data = format return nil }}// 获取错误码func errCodes(ctx context.Context, err error) (int, string) { if err != nil { log.CtxErrorf(ctx, "error: [% v]", err) } var myError = new(erro.IError) if errors.As(err, &myError) { return myError.Code, myError.Msg } return code.ServerError, i18n.CodeMessage(code.ServerError)}

如果和其他库进行协作,考虑使用errors.Wrap或者errors.Wrapf保存堆栈信息。同样适用于和标准库协作的时候。

_, err := os.Open(path)if err != nil { return errors.Wrapf(err, "Open failed. [%s]", path)}

最终效果样例:

go程序运行环境配置(3种方式GoError处理最佳实践)(2)

关键点总结:

四、errgroup集中错误处理

官方的ErrGroup非常简单,其实就是解决小型多任务并发任务。基本用法golang.org/x/sync/errgroup包下定义了一个Group struct,它就是我们要介绍的ErrGroup并发原语,底层也是基于WaitGroup实现的。在使用ErrGroup时,我们要用到三个方法,分别是WithContext、Go和Wait。

(一)背景

通常,在写业务代码性能优化时经常将一个通用的父任务拆成几个小任务并发执行。此时需要将一个大的任务拆成几个小任务并发执行,来提高QPS,我们需要再业务代码里嵌入以下逻辑,但这种方式存在问题:

(二)errgroup函数签名

type Group func WithContext(ctx context.Context) (*Group, context.Context) func (g *Group) Go(f func error) func (g *Group) Wait error

整个包就一个Group结构体:

(三)使用案例

注意这里有一个坑,在后面的代码中不要把ctx当做父 context又传给下游,因为errgroup取消了,这个context就没用了,会导致下游复用的时候出错

func TestErrgroup { eg, ctx := errgroup.WithContext(context.Background) for i := 0; i < 100; i { i := i eg.Go(func error { time.Sleep(2 * time.Second) select { case <-ctx.Done: fmt.Println("Canceled:", i) return nil default: fmt.Println("End:", i) return nil }})} if err := eg.Wait; err != nil { log.Fatal(err) }}

(四)errgroup拓展包

B站拓展包

(https://github.com/go-kratos/kratos/blob/v0.3.3/pkg/sync/errgroup/errgroup.go)

相比官方的结构,B站的结构多出了一个函数签名管道和一个函数签名切片,并把Context直接放入了返回的Group结构,返回仅返回一个Group结构指针。

type Group struct { err error wg sync.WaitGroup errOnce sync.Once workerOnce sync.Once ch chan func(ctx context.Context) error chs func(ctx context.Context) error ctx context.Context cancel func}func WithContext(ctx context.Context) *Group { return &Group{ctx: ctx}}

Go方法可以看出并不是直接起协程的(如果管道已经初始化好了),而是优先将函数签名放入管道,管道如果满了就放入切片。

func (g *Group) Go(f func(ctx context.Context) error) { g.wg.Add(1) if g.ch != nil { select { case g.ch <- f: default: g.chs = append(g.chs, f) } return } go g.do(f)}

GOMAXPROCS函数其实是起了一个并发池来控制协程数量,传入最大协程数量进行并发消费管道里的函数签名:

func (g *Group) GOMAXPROCS(n int) { if n <= 0 { panic("errgroup: GOMAXPROCS must great than 0") } g.workerOnce.Do(func { g.ch = make(chan func(context.Context) error, n) for i := 0; i < n; i { go func { for f := range g.ch { g.do(f) } } } })}

整个流程梳理下来其实就是启动一个固定数量的并发池消费任务,Go函数其实是向管道中发送任务的生产者,这个设计中有意思的是他的协程生命周期的控制,他的控制方式是每发送一个任务都进行WaitGroup加一,在最后结束时的wait函数中进行等待,等待所有的请求都处理完才会关闭管道,返出错误。

tips:

作者简介

李森林

腾讯后台工程师

腾讯后台工程师,目前负责腾讯游戏内容平台的设计、开发和维护工作。

本文由高可用架构翻译。技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式

,