更優雅的 Golang 錯誤處理

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

Golang 中的錯誤處理是一個被大家經常拿出來討論的話題(另外一個是泛型)。其中泛型這個問題，rsc 在最近的計劃中也提出了納入他今年的考慮計劃中，同時，泛型的提案在2016年也進行了一些更新，相信未來會有一些更好的方案提出。這個文章我們討論一下如何在現行的 Golang 架構下提供更友好和優雅的錯誤處理。

從現狀談起

Golang 中的錯誤處理原則，開發人員曾經之前專門發布了幾篇文章( Error handling and Go 和 Defer, Panic, and Recover、Errors are values )介紹。分別介紹了 Golang 中處理一般預知到的錯誤與遇到崩潰時的錯誤處理機制。

一般情況下，我們還是以官方部落格中的錯誤處理例子為例：

func main() {    f, err := os.Open("filename.ext")    if err != nil {        log.Fatal(err)        // 或者更簡單的：        // return err    }    ...}

當然對於簡化程式碼數，還有另外一種寫法：

func main() {    ...    if f, err = os.Open("filename.ext"); err != nil{        log.Fatal(err)    }    ...}

正常情況下，Golang 現有的哲學中，要求你盡量手工處理所有的錯誤返回，這稍微增加了開發人員的心智負擔。關於這部分設計的討論，請參考本文最開始提供的參考連結，此處不做太多探討。

本質上，Golang 中的錯誤類型 error 是一個介面類型：

type error interface {    Error() string}

只要滿足這一介面定義的所有數值都可以傳入 error 類型的位置。在 Go Proverbs 中也提到了關於錯誤的描述： Errors are values。這一句如何理解呢？

Errors are values

事實上，在實際使用過程中，你可能也發現了對 Golang 而言，所有的資訊是非常不足的。比如下面這個例子：

buf := make([]byte, 100)n, err := r.Read(buf)buf = buf[:n]if err == io.EOF { log.Fatal("read failed:", err)}

事實上這隻會列印資訊 2017/02/08 13:53:54 read failed:EOF，這對我們真實環境下的錯誤調試與分析其實是並沒有任何意義的，我們在查看日誌擷取錯誤資訊的時候能夠擷取到的資訊十分有限。

於是乎，一些提供了上下文方式的一些錯誤處理形式便在很多類庫中非常常見：

err := os.Remove("/tmp/nonexist")log.Println(err)

輸出了：

2017/02/08 14:09:22 remove /tmp/nonexist: no such file or directory

這種方式提供了一種更加直觀的上下文資訊，比如具體出錯的內容，也可以是出現錯誤的檔案等等。通過查看Remove的實現，我們可以看到：

// PathError records an error and the operation and file path that caused it.type PathError struct {    Op   string    Path string    Err  error}func (e *PathError) Error() string { return e.Op + " " + e.Path + ": " + e.Err.Error() }// file_unix.go 針對 *nix 系統的實現// Remove removes the named file or directory.// If there is an error, it will be of type *PathError.func Remove(name string) error {    // System call interface forces us to know    // whether name is a file or directory.    // Try both: it is cheaper on average than    // doing a Stat plus the right one.    e := syscall.Unlink(name)    if e == nil {        return nil    }    e1 := syscall.Rmdir(name)    if e1 == nil {        return nil    }    // Both failed: figure out which error to return.    // OS X and Linux differ on whether unlink(dir)    // returns EISDIR, so can't use that. However,    // both agree that rmdir(file) returns ENOTDIR,    // so we can use that to decide which error is real.    // Rmdir might also return ENOTDIR if given a bad    // file path, like /etc/passwd/foo, but in that case,    // both errors will be ENOTDIR, so it's okay to    // use the error from unlink.    if e1 != syscall.ENOTDIR {        e = e1    }    return &PathError{"remove", name, e}}

實際上這裡 Golang 標準庫中返回了一個名為 PathError 的結構體，這個結構體定義了操作類型、路徑和原始的錯誤資訊，然後通過 Error 方法對所有資訊進行了整合。

但是這樣也會存在問題，比如需要進行單獨類型複雜的分類處理，比如上面例子中，需要單獨處理 PathError 這種問題，你可能需要一個單獨的類型推導：

err := xxxx()if err != nil {    swtich err := err.(type) {    case *os.PathError:        ...    default:        ...    }}

這樣反倒會增加錯誤處理的複雜度。同時，這些錯誤必須變為匯出類型，也會增加整個系統的複雜度。

另外一個問題是，我們在出現錯誤時，我們通常也希望擷取更多的堆棧資訊，方便我們進行後續的故障追蹤。在現有的錯誤體系中，這相對比較複雜：你很難通過一個介面類型擷取完整的呼叫堆疊。這時，我們可能就需要一個第三方庫區去解決遇到的這些錯誤處理問題。

還有一種情況是，我們希望在錯誤處理過程中同樣可以附加一些資訊，這些也會相對比較麻煩。

更優雅的錯誤處理

之前提到了多種實際應用情境中出現的錯誤處理方法和遇到的一些問題，這裡推薦使用第三方庫去解決部分問題：github.com/pkg/errors。

比如當我們出現問題時，我們可以簡單的使用 errors.New 或者 errors.Errorf 產生一個錯誤變數：

err := errors.New("whoops")// orerr := errors.Errorf("whoops: %s", "foo")

當我們需要附加資訊時，則可以使用：

cause := errors.New("whoops")err := errors.Wrap(cause, "oh noes")

當需要擷取呼叫堆疊時，則可以使用：

err := errors.New("whoops")fmt.Printf("%+v", err)

其他建議

在上面做類型推導時，我們發現在處理一類錯誤時可能需要多個錯誤類型，這可能在某些情況下相對來說比較複雜，很多時候我們可以使用介面形式去方便處理：

type temporary interface {    Temporary() bool}// IsTemporary returns true if err is temporary.func IsTemporary(err error) bool {    te, ok := errors.Cause(err).(temporary)    return ok && te.Temporary()}

這樣就可以提供更加方便的錯誤解析和處理。

廣告時間

我們正在招收新人 Gopher，應屆畢業生 or 實習生歡迎投遞簡曆。我們正在努力實現開發流程標準化，如果你想獲得提高，相信也是一個非常不錯的機會。簡曆投遞 kevin [at] yeeuu [dot] com。

Golang

• Like
• Tweet
• +1