導(dǎo)語?|?錯誤處理一直以一是編程必需要面對的問題，錯誤處理如果做的好的話，代碼的穩(wěn)定性會很好。不同的語言有不同的出現(xiàn)處理的方式。Go語言也一樣，在本篇文章中，我們來討論一下Go語言的錯誤處理方式。

（一）Error

錯誤是程序中可能出現(xiàn)的問題，比如連接數(shù)據(jù)庫失敗，連接網(wǎng)絡(luò)失敗等，在程序設(shè)計(jì)中，錯誤處理是業(yè)務(wù)的一部分。

Go內(nèi)建一個error接口類型作為go的錯誤標(biāo)準(zhǔn)處理

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

// 接口定義type error interface {   Error() string}

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

// 實(shí)現(xiàn)func New(text string) error {   return &errorString{text}}
type errorString struct {   s string}
func (e *errorString) Error() string {   return e.s}

（二）Exception

異常是指在不該出現(xiàn)問題的地方出現(xiàn)問題，是預(yù)料之外的，比如空指針引用，下標(biāo)越界，向空map添加鍵值等。

• 人為制造被自動觸發(fā)的異常，比如：數(shù)組越界，向空map添加鍵值對等。

• 手工觸發(fā)異常并終止異常，比如：連接數(shù)據(jù)庫失敗主動panic。

（三）panic

對于真正意外的情況，那些表示不可恢復(fù)的程序錯誤，不可恢復(fù)才使用panic。對于其他的錯誤情況，我們應(yīng)該是期望使用error來進(jìn)行判定。

go源代碼很多地方寫panic, 但是工程實(shí)踐業(yè)務(wù)代碼不要主動寫panic，理論上panic只存在于server啟動階段，比如config文件解析失敗，端口監(jiān)聽失敗等等，所有業(yè)務(wù)邏輯禁止主動panic，所有異步的goroutine都要用recover去兜底處理。

（四）總結(jié)

理解了錯誤和異常的真正含義，我們就能理解Go的錯誤和異常處理的設(shè)計(jì)意圖。傳統(tǒng)的try...catch...結(jié)構(gòu)，很容易讓開發(fā)人員把錯誤和異?；鞛橐徽劊踔涟褬I(yè)務(wù)錯誤處理的一部分當(dāng)做異常來處理，于是你會在程序中看到一大堆的catch...

Go開發(fā)團(tuán)隊(duì)認(rèn)為錯誤應(yīng)該明確地當(dāng)成業(yè)務(wù)的一部分，任何可以預(yù)見的問題都需要做錯誤處理，于是在Go代碼中，任何調(diào)用者在接收函數(shù)返回值的同時也需要對錯誤進(jìn)行處理，以防遺漏任何運(yùn)行時可能的錯誤。

異常則是意料之外的，甚至你認(rèn)為在編碼中不可能發(fā)生的，Go遇到異常會自動觸發(fā)panic（恐慌），觸發(fā)panic程序會自動退出。除了程序自動觸發(fā)異常，一些你認(rèn)為不可允許的情況你也可以手動觸發(fā)異常。

另外，在Go中除了觸發(fā)異常，還可以終止異常并可選的對異常進(jìn)行錯誤處理，也就是說，錯誤和異常是可以相互轉(zhuǎn)換的。

（一）經(jīng)典Go邏輯

直觀的返回error：

type ZooTour interface {    Enter() error     VisitPanda(panda *Panda) error     Leave() error}
// 分步處理，每個步驟可以針對具體返回結(jié)果進(jìn)行處理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保存到對象內(nèi)部，處理邏輯交給每個方法，本質(zhì)上仍是順序執(zhí)行。標(biāo)準(zhǔn)庫的bufio、database/sql包中的Rows等都是這樣實(shí)現(xiàn)的，有興趣可以去看下源碼：

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()        // 集中編寫業(yè)務(wù)邏輯代碼,最后統(tǒng)一處理error    if err := t.Err(); err != nil {        return errors.WithMessage(err, "ZooTour failed")    }    return nil}

（三）利用函數(shù)式編程延遲運(yùn)行

分離關(guān)注點(diǎn)-遍歷訪問用數(shù)據(jù)結(jié)構(gòu)定義運(yùn)行順序，根據(jù)場景選擇，如順序、逆序、二叉樹樹遍歷等。運(yùn)行邏輯將代碼的控制流邏輯抽離，靈活調(diào)整。kubernetes中的visitor對此就有很多種擴(kuò)展方式，分離了數(shù)據(jù)和行為，有興趣可以去擴(kuò)展閱讀：

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繼續(xù)執(zhí)行        }    }}

（四）三種方式對比

上面這三個例子，是Go項(xiàng)目處理錯誤使用頻率最高的三種方式，也可以應(yīng)用在error以外的處理邏輯。

• case1: 如果業(yè)務(wù)邏輯不是很清楚，比較推薦case1；

• case2: 代碼很少去改動，類似標(biāo)準(zhǔn)庫，可以使用case2；

• case3: 比較復(fù)雜的場景，復(fù)雜到抽象成一種設(shè)計(jì)模式。

（一）一個常見的三層調(diào)用

在工程實(shí)踐中，以一個常見的三層架構(gòu)（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)}

（二）問題總結(jié)

• 分層開發(fā)導(dǎo)致的處處打印日志；

  
  

• 難以獲取詳細(xì)的堆棧關(guān)聯(lián)；

  
  

• 根因丟失。

（三）Wrap erros

Go相關(guān)的錯誤處理方法很多，但大多為過渡方案，這里就不一一分析了（類似github.com/juju/errors庫，有興趣可以了解）。這里我以github.com/pkg/errors為例，這個也是官方Proposal的重點(diǎn)參考對象。

1. 錯誤要被日志記錄；

   
   

2. 應(yīng)用程序處理錯誤，保證100%完整性；

   
   

3. 之后不再報(bào)告當(dāng)前錯誤（錯誤只被處理一次）。

github.com/pkg/errors包主要包含以下幾個方法，如果我們要新生成一個錯誤，可以使用New函數(shù),生成的錯誤，自帶調(diào)用堆棧信息。如果有一個現(xiàn)成的error ，我們需要對他進(jìn)行再次包裝處理，這時候有三個函數(shù)可以選擇（WithMessage/WithStack/Wrapf）。其次，如果需要對源錯誤類型進(jìn)行自定義判斷可以使用Cause,可以獲得最根本的錯誤原因。

// 新生成一個錯誤, 帶堆棧信息func New(message string) error
// 只附加新的信息func WithMessage(err error, message string) error
// 只附加調(diào)用堆棧信息func WithStack(err error) error
// 同時附加堆棧和信息func Wrapf(err error, format string, args ...interface{}) error
// 獲得最根本的錯誤原因func Cause(err error) error

以常見的一個三層架構(gòu)為例：

• Dao層使用Wrap上拋錯誤

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

• Service層追加信息

  
  

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

• MiddleWare統(tǒng)一打印錯誤日志

// 請求響應(yīng)組裝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)}

• 和其他庫進(jìn)行協(xié)作
  

如果和其他庫進(jìn)行協(xié)作，考慮使用errors.Wrap或者errors.Wrapf保存堆棧信息。同樣適用于和標(biāo)準(zhǔn)庫協(xié)作的時候。

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

• 包內(nèi)如果調(diào)用其他包內(nèi)的函數(shù)，通常簡單的直接return err

最終效果樣例：

關(guān)鍵點(diǎn)總結(jié)：

• MyError作為全局error的底層實(shí)現(xiàn)，保存具體的錯誤碼和錯誤信息；

• MyError向上返回錯誤時，第一次先用Wrap初始化堆棧，后續(xù)用WithMessage增加堆棧信息；

• 要判斷error是否為指定的錯誤時，可以使用errors.Cause獲取root error，再進(jìn)行和sentinel error判定；

• github.com/pkg/errors和標(biāo)準(zhǔn)庫的error完全兼容，可以先替換、后續(xù)改造歷史遺留的代碼；

• 打印error的堆棧需要用%+v，而原來的%v依舊為普通字符串方法；同時也要注意日志采集工具是否支持多行匹配；

• log error級別的打印棧，warn和info可不打印堆棧；

• 可結(jié)合統(tǒng)一錯誤碼使用：

  https://google-cloud.gitbook.io/api-design-guide/errors

官方的ErrGroup非常簡單，其實(shí)就是解決小型多任務(wù)并發(fā)任務(wù)?；居梅╣olang.org/x/sync/errgroup包下定義了一個Group struct，它就是我們要介紹的ErrGroup并發(fā)原語，底層也是基于WaitGroup實(shí)現(xiàn)的。在使用ErrGroup時，我們要用到三個方法，分別是WithContext、Go和Wait。

（一）背景

通常，在寫業(yè)務(wù)代碼性能優(yōu)化時經(jīng)常將一個通用的父任務(wù)拆成幾個小任務(wù)并發(fā)執(zhí)行。此時需要將一個大的任務(wù)拆成幾個小任務(wù)并發(fā)執(zhí)行，來提高QPS，我們需要再業(yè)務(wù)代碼里嵌入以下邏輯，但這種方式存在問題：

• 每個請求都開啟goroutinue，會有一定的性能開銷。

• 野生的goroutinue，生命周期管理比較困難。

• 收到類似SIGQUIT信號時，無法平滑退出。

（二）errgroup函數(shù)簽名

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

整個包就一個Group結(jié)構(gòu)體：

• 通過WithContext可以創(chuàng)建一個帶取消的Group；

• 當(dāng)然除此之外也可以零值的Group也可以直接使用，但是出錯之后就不會取消其他的goroutine了；

• Go方法傳入一個func() error內(nèi)部會啟動一個goroutine去處理；

• Wait類似WaitGroup的Wait方法，等待所有的goroutine結(jié)束后退出，返回的錯誤是一個出錯的err。

（三）使用案例

注意這里有一個坑，在后面的代碼中不要把ctx當(dāng)做父 context又傳給下游，因?yàn)閑rrgroup取消了，這個context就沒用了，會導(dǎo)致下游復(fù)用的時候出錯

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）

相比官方的結(jié)構(gòu)，B站的結(jié)構(gòu)多出了一個函數(shù)簽名管道和一個函數(shù)簽名切片,并把Context直接放入了返回的Group結(jié)構(gòu)，返回僅返回一個Group結(jié)構(gòu)指針。

?

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方法可以看出并不是直接起協(xié)程的（如果管道已經(jīng)初始化好了），而是優(yōu)先將函數(shù)簽名放入管道，管道如果滿了就放入切片。

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函數(shù)其實(shí)是起了一個并發(fā)池來控制協(xié)程數(shù)量，傳入最大協(xié)程數(shù)量進(jìn)行并發(fā)消費(fèi)管道里的函數(shù)簽名：

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

整個流程梳理下來其實(shí)就是啟動一個固定數(shù)量的并發(fā)池消費(fèi)任務(wù)，Go函數(shù)其實(shí)是向管道中發(fā)送任務(wù)的生產(chǎn)者，這個設(shè)計(jì)中有意思的是他的協(xié)程生命周期的控制，他的控制方式是每發(fā)送一個任務(wù)都進(jìn)行WaitGroup加一，在最后結(jié)束時的wait函數(shù)中進(jìn)行等待，等待所有的請求都處理完才會關(guān)閉管道，返出錯誤。

tips:

• B站拓展包主要解決了官方ErrGroup的幾個痛點(diǎn)：控制并發(fā)量、Recover住協(xié)程的Panic并打出堆棧信息。

• Go方法并發(fā)的去調(diào)用在量很多的情況下會產(chǎn)生死鎖，因?yàn)樗那衅皇蔷€程安全的，如果要并發(fā)，并發(fā)數(shù)量一定不能過大，一旦動用了任務(wù)切片，那么很有可能就在wait方法那里hold住了。這個可以加個鎖來優(yōu)化。

• Wg watigroup只在Go方法中進(jìn)行Add()，并沒有控制消費(fèi)者的并發(fā)，Wait的邏輯就是分發(fā)者都分發(fā)完成，直接關(guān)閉管道，讓消費(fèi)者并發(fā)池自行銷毀，不去管控，一旦邏輯中有完全hold住的方法那么容易產(chǎn)生內(nèi)存泄漏。

李森林

騰訊后臺工程師

騰訊后臺工程師，目前負(fù)責(zé)騰訊游戲內(nèi)容平臺的設(shè)計(jì)、開發(fā)和維護(hù)工作。

生于云，長于云，開發(fā)者如何更好地吃透云原生？

從0到1詳解ZooKeeper的應(yīng)用場景及架構(gòu)原理！

分布式事務(wù)解決方案：從了解到放棄！

Go語言從0到1實(shí)現(xiàn)最簡單的數(shù)據(jù)庫！