這一篇文章我們來探討一下怎么在項目初期提前規劃，把項目的各種Error統一管理起來，以及寫代碼遇到Error時在不同的代碼層我們應該怎么處理它們。

圖片

怎么把項目的Error管理起來

在聊怎么把Error管理起來之前我們先來聊一下為什么要管理Error，有Error就有Error唄，把信息返回給調用者不就行了？這里說的調用者指的是請求我們系統API的調用方。

乍一想好像確實沒毛病，但是咱們把眼光放到團隊開發和對接上。

其一：與咱們對接的系統，判斷錯誤一般靠的都是錯誤響應里的Code碼，如果同一個類型的錯誤你返回不同的錯誤碼，一兩個還好，如果十個八個估計對方就要過來找你們算帳了。

其二：既然一類錯誤的錯誤碼要統一，那每次都自己NewError再設置它的錯誤碼，這樣即使只有一個人開發這個項目，次數多了也會把錯誤碼寫錯的，更別提多個人一起開發的時候了。

所以就需要我們先把常見的能想到的錯誤預先定義出來。這也就是為什么咱們的項目在error模塊的code.go中預先定義了下面幾個基礎的錯誤。

var (
 Success            = newError(0, "success")
 ErrServer          = newError(10000000, "服務器內部錯誤")
 ErrParams          = newError(10000001, "參數錯誤, 請檢查")
 ErrNotFound        = newError(10000002, "資源未找到")
 ErrPanic           = newError(10000003, "(*^__^*)系統開小差了,請稍后重試") // 無預期的panic錯誤
 ErrToken           = newError(10000004, "Token無效")
 ErrForbidden       = newError(10000005, "未授權") // 訪問一些未授權的資源時的錯誤
 ErrTooManyRequests = newError(10000006, "請求過多")
 ErrCoverData       = newError(10000007, "ConvertDataError") // 數據轉換錯誤
)

除了這些通用的錯誤之外，我們可以預先按照項目的模塊分配每個業務模塊錯誤的碼段。比如在未來的項目代碼中你會看到一些給業務模塊單獨定義的錯誤碼。

// 用戶模塊相關錯誤碼 10000100 ~ 1000199
var (
 ErrUserInvalid      = newError(10000101, "用戶異常")
 ErrUserNameOccupied = newError(10000102, "用戶名已被占用")
  ...
)

// 商品模塊相關錯誤碼 10000200 ~ 1000299
var (
 ErrCommodityNotExists = newError(10000200, "商品不存在")
 ErrCommodityStockOut  = newError(10000201, "庫存不足")
  ...
)

// 購物車模塊相關錯誤碼 10000300 ～ 1000399
var (
 ErrCartItemParam = newError(10000300, "購物項參數異常")
 ErrCartWrongUser = newError(10000301, "用戶購物信息不匹配")
  ...
)

到這里一直說的都是預先定義錯誤，那針對一些不知道什么類型的錯誤該怎么辦？比如在DAO層做了一下CRUD出現了Error，難道還要預先定義一個ErrDBQuery 之類的錯誤嗎？那項目用的中間件多了，Redis、MQ什么的都要預先定義錯誤嗎？

這里我給我的方案是，調用其他外部基礎組件出錯時，調用一個SDK方法出錯時，把底層錯誤包裝成項目的Error。

func Wrap(msg string, err error) *AppError {
 if err == nil {
  return nil
 }
 appErr := &AppError{code: -1, msg: msg, cause: err}
 return appErr
}

當你拿到一個error不確定它該是什么錯誤，你就用這個Wrap方法包裝成項目的App Error。

下一節我們封裝的統一接口響應組件會使用下面的方法來獲取Error對應的HTTP Code。

func (e *AppError) HttpStatusCode() int {
 switch e.Code() {
 case Success.Code():
  return http.StatusOK
 case ErrParams.Code():
  return http.StatusBadRequest
 case ErrNotFound.Code():
 ......
 default:
  return http.StatusInternalServerError
 }
}

不同代碼層該怎么處理Error

我們在寫代碼的時候為了保險，都愛在 error 判斷中打一條Error級別的日志，這樣好歹遇到錯誤了在日志中會留下痕跡，到了真需要排除問題的時候總比那些什么日志都不記錄的寫法要好多了。

很多時候我們遇到線上問題了，查半天最后實現沒辦法就加幾條日志部署上去觀察觀察情況，等同樣的錯誤發生了再去看新打的日志。

但是不知道大家有沒有發現，如果你每遇到Error都打一條日志的話，那么這個錯誤信息在日志里的重復率時相當的高，發生了一個錯誤，好幾條日志都是這個錯誤信息，其實都是同一個錯誤，只不過這些日志是在調用邏輯的不同代碼層做被打進去的。

那么關于什么錯誤該記日志，什么不該記，有沒有什么好用的標準？不好意思沒有，全靠自己的悟性。。。。。。聽到這里是不是想罵人了。

這里分享一下國外論壇中經常看到的 Only handle errors once的原則

Go程序錯誤處理的原則：

• 程序底層 （Dao、基礎設施層） 拋出錯誤
• 程序中層（領域服務層、應用服務層）包裝錯誤
• 程序上層（控制層） 記錄錯誤

如果每一層都打日志，查詢日志的時候必然會有不少重復，當然這個見仁見智，多打點日志也沒錯總比不打日志，出問題了再打日志，等線上復現問題后再排查日志要強多了。

還有一個原因就是Go的原生 Error 如果你不自己做自定義封裝確實能給咱們的有效信息很少，我們看到錯誤信息經常是找半天才能找到原因。