沒有 try-catch，該如何處理 Go 錯誤例外？

錯誤處理是軟體開發中不可回避的問題，「Go 中主要通過 error 和 panic 分別表示錯誤和例外」，并提供了較為簡潔的錯誤例外處理機制，本文我們就來介紹 Go 中的一些錯誤處理機制，再聊聊 Go 語言中錯誤處理的槽點和期望，

Errorsare values

錯誤處理是每個開發人員都需要面對的問題，在我過去接觸的編程語言中，大多是通過「try-catch 的方式」對可能出現錯誤的代碼塊進行包裝：「程式運行 try 中代碼，如果 try 中的代碼運行出錯，程式將會立即跳轉到 catch 中執行例外處理邏輯」，

與其他的編程語言不同，Go中倡導“Errorsare values!”的處理思想，它將 error 作為一個回傳值，來迫使呼叫者對 error 進行處理或者忽略，于是，在代碼中我們將會撰寫大量的 if 判斷陳述句對 error 進行判斷，如下所示：

result, err := dothing("work")
if err != nil {
log.Fatal(err)
}
// do other thing

當專案的代碼快速增長起來時，我們會發現代碼中到處都是類似 err != nil 的判斷片段，雖然這會使代碼變得很煩瑣，但是這種設計和約定也會鼓勵開發人員明確檢查和確定錯誤發生的位置，

在 Go 中，error 介面定義如下：

type error interface {
Error() string
}

最常用的 error 實作是 Go 標準庫 errors 包中內置的 errorString，它是一個僅包含錯誤資訊的error 實作，可以通過 errors.New 和 fmt.Errorf 函式創建，內置的 error 介面使得開發人員可以為錯誤添加任何所需的資訊，error 可以是實作 Error() 方法的任何型別，比如我們可以為錯誤添加錯誤碼和呼叫堆疊資訊，如下所示：

type Error struct {
Msg string
Code int32
St []uintptr // 呼叫堆疊
}
// 獲取呼叫堆疊資訊
func callers() []uintptr {
var pcs [32]uintptr
n := runtime.Callers(3, pcs[:])
st := pcs[0:n]
return st
}
func New(code int32, msg string) error {
return &Error{
Code: int32(code),
Msg:  msg,
St: callers(),
}
}
func (e *Error) Error() string {
if e == nil {
return "OK"
}
return fmt.Sprintf("code:%d, msg:%s", e.Code, e.Msg)
}

通過「斷言」的方式可以將 error 轉化為特定的型別從而進行特異化處理，如下所示：

if e, ok := err.(*Error); ok {
// 取出堆疊資訊進行處理
st := e.st
// ....
}else {
// 其他錯誤處理
}

在 Go 1.13版本之后，errors 包中添加了errors.Is 和 errors.As 函式：errors.Is 方法用來比較兩個 error 是否相等，而 errors.As 函式用來判斷 error 是否為特定型別，

由于 error 是一個值，因此我們可以對其進行編程，簡化 Go 錯誤處理的重復代碼，在一些管道和回圈的代碼中，只要其中一次處理出現錯誤，就應該退出本次管道或者回圈，尋常的做法是在每次迭代都檢查錯誤，但為了讓管道和回圈的操作顯得更加自然，我們可以將 error 封裝到獨立的方法或者變數中回傳，以避免錯誤處理掩蓋控制流程，如 gorm 中的 DB 設計所示：

err := DB.Where(queryString, queryValue...).
Table("table_name").
Updates(map[string]interface{}{...}).Error
if err != nil{
// 錯誤處理邏輯
}

這里error 是從 gorm.DB 的 Error 成員變數中獲取的，在資料庫請求執行結束之后，程式才從 DB 中獲取執行錯誤，這樣的寫法使得錯誤處理不會中斷執行流程，但需要注意的是，無論如何簡化 error 的設計，程式都要檢查和處理錯誤，錯誤是無法避免的，

defer、panic 和 recover

錯誤一般是一些開發人員“意料之內”的錯誤，比如獲取資料庫連接失敗等，這些都是在 Go 中通過 error 表達并可控，但當程式出現例外，如陣列訪問越界這類“意料之外”的錯誤時，它能夠導致程式運行崩潰，此時就需要開發人員捕獲例外并恢復程式的正常運行流程，

接下來我們就介紹defer、panic 和 recover 如何組合恢復運行時執行例外的 Go 程式，

「defer 是 Go 中提供的一種延遲執行機制」，每次執行 defer，都會將對應的函式壓入堆疊中，在函式回傳或者 panic 例外結束時，Go 會依次從堆疊中取出延遲函式執行，

在編程的時候，經常需要打開一些資源，比如資料庫連接、檔案等，在資源使用完成之后需要釋放，不然有可能會造成資源泄漏，這個時候，我們可以通過 defer 陳述句在函式執行完之后，自動釋放資源，避免在每個函式回傳之前手動釋放資源，減少冗余代碼，

defer 有三個比較重要的特點，「第「「一個」」是****按照呼叫 defer 的逆序執行」，即后呼叫的在函式退出時先執行，「后進先出」，如下例子所示:

func main()  {
 defer fmt.Println("I register at first, but execute at last")
 defer fmt.Println("I register at middle, execute at middle")
 defer fmt.Println("I register at last, execute at first")
 fmt.Println("test begin")
}

預期的結果為：

test begin
I register at last, execute at first
I register at middle, execute at middle
I register at first, but execute at last

「第二」個特點是 「defer 被定義時，引數變數會被立即決議，傳遞引數的值拷貝」，在函式內使用的變數其實是對外部變數的一個拷貝，在函式體內，對變數更改也不會影響外部變數，如下所示：

func main()  {
 i := 10
 defer fmt.Printf("defer i is %d\n", i)
 i = 20
 fmt.Printf("current i is %d\n", i)
}

預期結果為：

current i is 20
defer i is 10

然而當 defer 以閉包的方式參考外部變數時，則會在延遲函式真正執行的時候，根據整個背景關系確定當前的值，如下示例代碼：

func main()  {
for i := 0; i < 5; i++ {
defer func() {
fmt.Println(i)
}()
}
}

預期的輸出結果為：

5
5
5
5
5

上述例子為了演示簡單，在 for 回圈中使用了defer，但**在日常開發中，「我建議你還是不要在回圈中使用 defer」，因為相較于直接呼叫，defer 的執行存在著額外的開銷，例如defer 會對其后需要的引數進行記憶體拷貝，還會對 defer 結構進行壓堆疊出堆疊操作，因此，在回圈中使用 defer 可能會帶來較大的性能開銷，

「defer的第三個特點是可以讀取并修改函式的命名回傳值」，如下面的例子所示：

func main()  {
 fmt.Println(test())
}
func test() (i int) {
 defer func() { i++ }()
 return 1
}

預期的回傳結果為：

2

這是因為對于命名回傳值，defer 和 return 的執行順序如下：

• 將 1 賦給 i；

• 執行 i++；

• 回傳 i 作為函式回傳值，

defer 的內部實作為一個「延遲呼叫鏈表」，如下圖所示：

defer延遲呼叫鏈表示意圖

其中，g 代表 goroutine 的資料結構，每個 goroutine 中都有一個 _defer 鏈表，當代碼中遇到 defer 關鍵字時，Go 都會將 defer 相關的函式和引數封裝到 _defer 結構體中，然后將其注冊到當前 goroutine 的 _defer 鏈表的表頭，在當前函式執行完畢之后，Go 會從goroutine的 _defer 鏈表頭部取出來注冊的 defer 執行并回傳，

_defer 結構體中存盤 defer 執行相關的資訊，定義如下所示：

type _defer struct {
siz       int32 // 引數與結果記憶體大小
started   bool
heap      bool // 是否在堆上分配
openDefer bool //是否經過開放編碼優化
sp        uintptr // 堆疊指標
pc        uintptr // 呼叫方的程式計數器
fn        *funcval // defer 傳入的函式
_panic    *_panic
link      *_defer // 下一個 _defer
}

「panic 是一個內置函式，用于拋出程式執行的例外」，它會終止其后將要執行的代碼，并依次逆序執行 panic 所在函式可能存在的 defer 函式串列；然后回傳該函式的呼叫方，如果函式的呼叫方中也有 defer 函式串列，也將被逆序執行，執行結束后再回傳到上一層呼叫方，直到回傳當前 goroutine 中的所有函式為止，最后報告例外，程式崩潰退出，例外可以直接通過 panic 函式呼叫拋出，也可能是因為運行時錯誤而引發，比如訪問了空指標等，

而「recover 內置函式可用于捕獲 panic，重新恢復程式正常執行流程，但是 recover 函式只有在 defer 內部使用才有效」，如下面例子所示：

func main() {
err := panicAndReturnErr()
if err != nil{
fmt.Printf("err is %+v\n", err)
}
fmt.Println("returned normally from panicAndReturnErr")
}
func panicAndReturnErr() (err error){
defer func() {
        // 從 panic 中恢復
if e := recover(); e != nil {
            // 列印堆疊資訊
buf := make([]byte, 1024)
buf = buf[:runtime.Stack(buf, false)]
err = fmt.Errorf("[PANIC]%v\n%s\n", e, buf)
}
}()
fmt.Println("panic begin")
panic("panic this game")
fmt.Println("panic over")
return nil
}

預期的執行結果為：

panic begin
err is [PANIC]panic this game
goroutine 1 [running]:
main.panicAndReturnErr.func1(0xc000062f08)
/Users/apple/Desktop/micro-go-course/p37/defer_example.go:21 +0xa1
panic(0x10ad640, 0x10eb360)
/usr/local/go/src/runtime/panic.go:969 +0x166
main.panicAndReturnErr(0x0, 0x0)
/Users/apple/Desktop/micro-go-course/p37/defer_example.go:26 +0xc2
main.main()
/Users/apple/Desktop/micro-go-course/p37/defer_example.go:10 +0x26
returned normally from panicAndReturnErr

從這個執行結果可以看出，panicAndReturnErr 函式在 panic 之后將會執行 defer 定義的延遲函式，恢復程式的正常執行邏輯，在上述例子中，我們在 defer 函式中使用 recover 函式幫助程式從 panic 中恢復過來，并獲取例外堆疊資訊組成 error 回傳呼叫方，panicAndReturnErr 從 panic 中恢復后將直接回傳，不會執行函式中 panic 后的其他代碼，

在日常開發中，對于可能出現執行例外的函式，如陣列越界、操作空指標等，在函式中定義一個使用 recover 函式的 defer 延遲函式，有利提高程式執行的健壯性，避免程式運行時例外崩潰，

Go 錯誤處理的一些吐槽

Go 語言的錯誤處理在社區一直有爭議，Go 錯誤處理方式也一直是很多人詬病的地方，有些人吐槽說一半的代碼都是 if err != nil { / 列印 && 錯誤處理 / }，嚴重影響正常的處理邏輯，

Go 使用的是對顯式錯誤結果的顯式錯誤檢查，而其他例外處理型語言（諸如C++，C#，Java等）使用的是對隱式結果進行隱式檢查，對于例外處理型語言的處理方式，因我們全然看不到隱式檢查，所以難以驗證程式是否正確恢復到檢查失敗時的狀態，當我們區分錯誤和例外，根據規則設計函式，就會大大提高可讀性和可維護性，

我們往往期望的是在代碼中減少大量錯誤檢查代碼，使錯誤檢查更輕量，使錯誤處理更便捷，所以期待在后面的 Go 版本能夠減少重復地例外處理，使得錯誤檢查及錯誤處理保持顯式的方式，并兼容現有代碼，

小結

本文我們主要介紹了Go 中常見的錯誤處理機制 Go 倡導將錯誤作為回傳值回傳給呼叫方，由呼叫方決定如何處理或者忽略錯誤，通過 defer 和 recover 內置函式，我們可以輕易地將運行時例外的 Go 程式恢復到正常執行流程，從程式開發的角度來說，建立'速錯'理念，程式終止了，你就會第一時間知道錯誤，因此，我們在早期開發階段，最簡單的同時也可能是最好的方法是呼叫panic函式來中斷程式的執行以強制發生錯誤，使得該錯誤不會被忽略，因而能夠盡快修復，保證應用程式的穩定性，

推薦閱讀

Serverless 架構就不要服務器了？

微服務架構中使用 ELK 進行日志采集以及統一處理

如何使用 Prometheus 和 Grafana 監控預警服務集群？

訂閱最新文章，歡迎關注我的公眾號