前言

最近在對極客時間毛劍老師的 Go 進階訓練營進行重溫和學習匯總，這是一門比較偏向于工程化以及原理層面的的課程，涵蓋的知識點非常多，因此決定開一個系列來進行記錄，也便于自己總結查閱。

Go 錯誤處理機制

Go 內(nèi)置 errors

Go 語言中的?error?就是普通的一個接口，表示值

// http://golang.org/pkg/builtin/#error
// error 接口的定義
type error interface {
    Error() string
}
// http://golang.org/pkg/errors/error.go
// errors 構建 error 對象
type errorString struct {
    s string
}
func (e *errorString) Error() string {
    return e.s
}

基礎庫中有大量自定義的?error，如?Error: EOF，而?errors.New()?返回的是內(nèi)部?errorString?對象的指針。

Error 與 Exception

不同于 Java、C++ 等語言，Go 處理異常的邏輯是不引入 exception，而是采取多參數(shù)返回，因此可以在函數(shù)中帶入 error interface 對象來交給調(diào)用者來進行處理。

func handle() (int, error) {
    return 1, nil
}
func main() {
    i, err := handle()
    if err != nil {
        return
    }
    // 其他處理邏輯
}

需要注意的是，Go 中有 panic 的機制，可以和 recovery 搭配實現(xiàn)類似于?try...exception...?的效果，但是 Go 中的 panic 并不等同于 exception，exception 一般是交由調(diào)用者來進行處理，而 Go panic 則是針對真正異常的情況（如索引越界、棧溢出、不可恢復的環(huán)境問題等），意味著代碼不能繼續(xù)運行，而不能假設調(diào)用者會來解決 panic。

Go 的多返回值來支持調(diào)用者進行錯誤處理的方式給予了開發(fā)者很大的靈活性，有如下優(yōu)勢

• 簡單
• Plan for failure, not success
• 沒有隱藏的控制流
• 完全交給開發(fā)者來控制 error
• error 是值，因此有很大的靈活性進行處理

Go 錯誤處理最佳實踐

panic

panic 只用于真正異常的情況，如

• 在程序啟動的時候，如果有強依賴的服務出現(xiàn)故障時 panic 退出
• 在程序啟動的時候，如果發(fā)現(xiàn)有配置明顯不符合要求， 可以 panic 退出（防御編程）
• 在程序入口處，例如 gin 中間件需要使用 recovery 預防 panic 程序退出

因為 panic 會導致程序直接退出，而如果使用 recovery 進行處理的話性能不好且不可控。因此，其他情況下只要不是不可恢復的程序錯誤，都不應該直接 panic 應該返回 error，從而交給開發(fā)者。

error

一般我們在開發(fā)中會使用?github.com/pkg/errors?處理應用錯誤，但需要注意的是，在公共庫當中，我們一般不使用。

在通過多返回值來判斷錯誤時，error?應該是函數(shù)的最后一個返回值，而當?error?不是?nil?時，其他返回值均應該為不可用狀態(tài)，不應該對它們進行額外處理，錯誤處理的時候也應該先判斷錯誤，當?if err != nil?時及時返回錯誤，從而避免過多的代碼嵌套。

// 錯誤示例
func f() error {
    ans, err := someFunc()
    if err == nil {
        // 其他邏輯
    }
    return err
}
// 正確示例
func f() error {
    ans, err := someFunc()
    if err != nil {
        return err
    }
    // 其他邏輯
    return nil
}

當程序出現(xiàn)錯誤時，一般使用?errors.New?或?errors.Errorf?返回錯誤值

func someFunc() error {
    res := anotherFunc()
    if res != true {
        errors.Errorf("結果錯誤，已嘗試 %d 次", count)
    }
    // 其他邏輯
    return nil
}

而如果是調(diào)用其他函數(shù)出現(xiàn)問題，則應該直接返回，如果需要攜帶額外信息，則使用?errors.WithMessage。

func someFunc() error {
    res, err := anotherFunc()
    if err != nil {
        return errors.WithMessage(err, "other information")
    }
}

如果是調(diào)用其他庫（標準庫、企業(yè)公共庫、開源第三方庫等）獲取到錯誤時，請使用?errors.Wrap?添加堆棧信息。只需要在錯誤第一次出現(xiàn)時使用，且在基礎庫和被大量引用的第三方庫編寫時一般不使用，避免堆棧信息重復。

func f() error {
    err := json.Unmashal(&a, data)
    if err != nil {
        return errors.Wrap(err, "other information")
    }
    // 其他邏輯
    return nil
}

當需要對錯誤進行判斷時，需要采用?errors.Is?進行比較

func f() error {
    err := A()
    if errors.Is(err, io.EOF){
        return nil
    }
    // 其他邏輯
    return nil
}

而對錯誤類型進行判斷時則使用?errors.As?進行賦值

func f() error {
    err := A()
    var errA errorA
    if errors.As(err, &errA){
        // ...
    }
    // 其他邏輯
    return nil
}

對于業(yè)務中的錯誤（如輸入錯誤等），最好在統(tǒng)一的一個地方建立自己的錯誤字典，其中應該包含錯誤代碼并且可以在日志中作為獨立字段打印，也需要有清晰的文檔。

我們常常用日志來輔助我們進行錯誤處理，不需要進行返回、被忽略的錯誤必須輸出日志，但禁止每個出錯的地方都打日志。而如果同一個地方不停地報錯，最好是打印一次錯誤詳情并打印出現(xiàn)次數(shù)。

總結

以上就是對 Go 錯誤處理和最佳實踐的一些總結，后續(xù)也會對錯誤類型、錯誤包裝以及常見的使用中遇到的坑等進行總結。

參考?golang?gorm錯誤處理事務以及日志用法示例