前言#
最近在對極客時間毛劍老師的 Go 進階訓練營進行重溫和學習彙總，這是一門比較偏向於工程化以及原理層面的課程，涵蓋的知識點非常多，因此決定開一個系列來進行記錄，也便於自己總結查閱。這是系列第一篇《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 錯誤處理和最佳實踐的一些總結，後續也會對錯誤類型、錯誤包裝以及常見的使用中遇到的坑等進行總結。