前言

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

Go 錯誤處理機制

Go 內置 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()?返回的是內部?errorString?對象的指針。

Error 與 Exception

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

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

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

Go 的多返回值來支持調用者進行錯誤處理的方式給予了開發者很大的靈活性，有如下優勢

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

Go 錯誤處理最佳實踐

panic

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

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

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

error

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

在通過多返回值來判斷錯誤時，error?應該是函數的最后一個返回值，而當?error?不是?nil?時，其他返回值均應該為不可用狀態，不應該對它們進行額外處理，錯誤處理的時候也應該先判斷錯誤，當?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
}

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

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

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

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

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

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
}

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

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

總結

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

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