Go項目Error的統(tǒng)一規(guī)劃管理和處理策略
這一篇文章我們來探討一下怎么在項目初期提前規(guī)劃，把項目的各種Error統(tǒng)一管理起來，以及寫代碼遇到Error時在不同的代碼層我們應(yīng)該怎么處理它們。
圖片
怎么把項目的Error管理起來
在聊怎么把Error管理起來之前我們先來聊一下為什么要管理Error，有Error就有Error唄，把信息返回給調(diào)用者不就行了？這里說的調(diào)用者指的是請求我們系統(tǒng)API的調(diào)用方。
乍一想好像確實沒毛病，但是咱們把眼光放到團隊開發(fā)和對接上。
其一：與咱們對接的系統(tǒng)，判斷錯誤一般靠的都是錯誤響應(yīng)里的Code碼，如果同一個類型的錯誤你返回不同的錯誤碼，一兩個還好，如果十個八個估計對方就要過來找你們算帳了。
其二：既然一類錯誤的錯誤碼要統(tǒng)一，那每次都自己NewError再設(shè)置它的錯誤碼，這樣即使只有一個人開發(fā)這個項目，次數(shù)多了也會把錯誤碼寫錯的，更別提多個人一起開發(fā)的時候了。
所以就需要我們先把常見的能想到的錯誤預(yù)先定義出來。這也就是為什么咱們的項目在error模塊的code.go中預(yù)先定義了下面幾個基礎(chǔ)的錯誤。
var (
Success = newError(0, "success")
ErrServer = newError(10000000, "服務(wù)器內(nèi)部錯誤")
ErrParams = newError(10000001, "參數(shù)錯誤, 請檢查")
ErrNotFound = newError(10000002, "資源未找到")
ErrPanic = newError(10000003, "(*^__^*)系統(tǒng)開小差了,請稍后重試") // 無預(yù)期的panic錯誤
ErrToken = newError(10000004, "Token無效")
ErrForbidden = newError(10000005, "未授權(quán)") // 訪問一些未授權(quán)的資源時的錯誤
ErrTooManyRequests = newError(10000006, "請求過多")
ErrCoverData = newError(10000007, "ConvertDataError") // 數(shù)據(jù)轉(zhuǎn)換錯誤
)除了這些通用的錯誤之外，我們可以預(yù)先按照項目的模塊分配每個業(yè)務(wù)模塊錯誤的碼段。比如在未來的項目代碼中你會看到一些給業(yè)務(wù)模塊單獨定義的錯誤碼。
// 用戶模塊相關(guān)錯誤碼 10000100 ~ 1000199
var (
ErrUserInvalid = newError(10000101, "用戶異常")
ErrUserNameOccupied = newError(10000102, "用戶名已被占用")
...
)
// 商品模塊相關(guān)錯誤碼 10000200 ~ 1000299
var (
ErrCommodityNotExists = newError(10000200, "商品不存在")
ErrCommodityStockOut = newError(10000201, "庫存不足")
...
)
// 購物車模塊相關(guān)錯誤碼 10000300 ～ 1000399
var (
ErrCartItemParam = newError(10000300, "購物項參數(shù)異常")
ErrCartWrongUser = newError(10000301, "用戶購物信息不匹配")
...
)到這里一直說的都是預(yù)先定義錯誤，那針對一些不知道什么類型的錯誤該怎么辦？比如在DAO層做了一下CRUD出現(xiàn)了Error，難道還要預(yù)先定義一個ErrDBQuery 之類的錯誤嗎？那項目用的中間件多了，Redis、MQ什么的都要預(yù)先定義錯誤嗎？
這里我給我的方案是，調(diào)用其他外部基礎(chǔ)組件出錯時，調(diào)用一個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。
下一節(jié)我們封裝的統(tǒng)一接口響應(yīng)組件會使用下面的方法來獲取Error對應(yīng)的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級別的日志，這樣好歹遇到錯誤了在日志中會留下痕跡，到了真需要排除問題的時候總比那些什么日志都不記錄的寫法要好多了。
很多時候我們遇到線上問題了，查半天最后實現(xiàn)沒辦法就加幾條日志部署上去觀察觀察情況，等同樣的錯誤發(fā)生了再去看新打的日志。
但是不知道大家有沒有發(fā)現(xiàn)，如果你每遇到Error都打一條日志的話，那么這個錯誤信息在日志里的重復率時相當?shù)母撸l(fā)生了一個錯誤，好幾條日志都是這個錯誤信息，其實都是同一個錯誤，只不過這些日志是在調(diào)用邏輯的不同代碼層做被打進去的。
那么關(guān)于什么錯誤該記日志，什么不該記，有沒有什么好用的標準？不好意思沒有，全靠自己的悟性。。。。。。聽到這里是不是想罵人了。
這里分享一下國外論壇中經(jīng)常看到的 Only handle errors once的原則
Go程序錯誤處理的原則：
- 程序底層 （Dao、基礎(chǔ)設(shè)施層） 拋出錯誤
- 程序中層（領(lǐng)域服務(wù)層、應(yīng)用服務(wù)層）包裝錯誤
- 程序上層（控制層） 記錄錯誤
如果每一層都打日志，查詢?nèi)罩镜臅r候必然會有不少重復，當然這個見仁見智，多打點日志也沒錯總比不打日志，出問題了再打日志，等線上復現(xiàn)問題后再排查日志要強多了。
還有一個原因就是Go的原生 Error 如果你不自己做自定義封裝確實能給咱們的有效信息很少，我們看到錯誤信息經(jīng)常是找半天才能找到原因。
