寫 Go 的人往往對(duì)它的錯(cuò)誤處理模式有一定的看法。按不同的語言經(jīng)驗(yàn)，人們可能有不同的習(xí)慣處理方法。這就是為什么我決定要寫這篇文章，盡管有點(diǎn)固執(zhí)己見，但我認(rèn)為聽取我的經(jīng)驗(yàn)是有用的。我想要講的主要問題是，很難去強(qiáng)制執(zhí)行良好的錯(cuò)誤處理實(shí)踐，錯(cuò)誤經(jīng)常沒有堆棧追蹤，并且錯(cuò)誤處理本身太冗長(zhǎng)。不過，我已經(jīng)看到了一些潛在的解決方案，或許能幫助解決一些問題。

與其他語言的快速比較

在 Go 中，所有的錯(cuò)誤都是值。因?yàn)檫@點(diǎn)，相當(dāng)多的函數(shù)***會(huì)返回一個(gè) error, 看起來像這樣：

func (s *SomeStruct) Function() (string, error) 

因此這導(dǎo)致調(diào)用代碼通常會(huì)使用 if 語句來檢查它們：

bytes, err := someStruct.Function()
if err != nil {
  // Process error
}

另外一種方法，是在其他語言中，如 Java、C#、Javascript、Objective C、Python 等使用的 try-catch 模式。如下你可以看到與先前的 Go 示例類似的 Java 代碼，聲明 throws 而不是返回 error：

public String function() throws Exception

它使用的是 try-catch 而不是 if err != nil：

try {
  String result = someObject.function()
  // continue logic
}
catch (Exception e) {
  // process exception
}

當(dāng)然，還有其他的不同。例如，error 不會(huì)使你的程序崩潰，然而 Exception 會(huì)。還有其他的一些，在本篇中會(huì)專門提到這些。

實(shí)現(xiàn)集中式錯(cuò)誤處理

退一步，讓我們看看為什么要在一個(gè)集中的地方處理錯(cuò)誤，以及如何做到。

大多數(shù)人或許會(huì)熟悉的一個(gè)例子是 web 服務(wù) - 如果出現(xiàn)了一些未預(yù)料的的服務(wù)端錯(cuò)誤，我們會(huì)生成一個(gè) 5xx 錯(cuò)誤。在 Go 中，你或許會(huì)這么實(shí)現(xiàn)：

func init() {
    http.HandleFunc("/users", viewUsers)
    http.HandleFunc("/companies", viewCompanies)
}
 
func viewUsers(w http.ResponseWriter, r *http.Request) {
    user // some code
    if err := userTemplate.Execute(w, user); err != nil {
        http.Error(w, err.Error(), 500)
    }
}
 
func viewCompanies(w http.ResponseWriter, r *http.Request) {
    companies = // some code
    if err := companiesTemplate.Execute(w, companies); err != nil {
        http.Error(w, err.Error(), 500)
    }
}

這并不是一個(gè)好的解決方案，因?yàn)槲覀儾坏貌恢貜?fù)地在所有的處理函數(shù)中處理錯(cuò)誤。為了能更好地維護(hù)，***能在一處地方處理錯(cuò)誤。幸運(yùn)的是，在 Go 語言的官方博客中，Andrew Gerrand 提供了一個(gè)替代方法，可以***地實(shí)現(xiàn)。我們可以創(chuàng)建一個(gè)處理錯(cuò)誤的 Type：

type appHandler func(http.ResponseWriter, *http.Request) error
 
func (fn appHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    if err := fn(w, r); err != nil {
        http.Error(w, err.Error(), 500)
    }
}

這可以作為一個(gè)封裝器來修飾我們的處理函數(shù)：

func init() {
    http.Handle("/users", appHandler(viewUsers))
    http.Handle("/companies", appHandler(viewCompanies))
}

接著我們需要做的是修改處理函數(shù)的簽名來使它們返回 errors。這個(gè)方法很好，因?yàn)槲覀冏龅搅?DRY 原則，并且沒有重復(fù)使用不必要的代碼 - 現(xiàn)在我們可以在單獨(dú)一個(gè)地方返回默認(rèn)錯(cuò)誤了。

錯(cuò)誤上下文

在先前的例子中，我們可能會(huì)收到許多潛在的錯(cuò)誤，它們中的任何一個(gè)都可能在調(diào)用堆棧的許多環(huán)節(jié)中生成。這時(shí)候事情就變得棘手了。

為了演示這點(diǎn)，我們可以擴(kuò)展我們的處理函數(shù)。它可能看上去像這樣，因?yàn)槟０鍒?zhí)行并不是唯一一處會(huì)發(fā)生錯(cuò)誤的地方：

func viewUsers(w http.ResponseWriter, r *http.Request) error {
    user, err := findUser(r.formValue("id")) 
    if err != nil {
      return err;
    }
    return userTemplate.Execute(w, user);
}

調(diào)用鏈可能會(huì)相當(dāng)深，在整個(gè)過程中，各種錯(cuò)誤可能在不同的地方實(shí)例化。Russ Cox的這篇文章解釋了如何避免遇到太多這類問題的***實(shí)踐：

“在 Go 中錯(cuò)誤報(bào)告的部分約定是函數(shù)包含相關(guān)的上下文，包括正在嘗試的操作(比如函數(shù)名和它的參數(shù))。”

這個(gè)給出的例子是對(duì) OS 包的一個(gè)調(diào)用：

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

它會(huì)輸出：

remove /tmp/nonexist: no such file or directory

總結(jié)一下，執(zhí)行后，輸出的是被調(diào)用的函數(shù)、給定的參數(shù)、特定的出錯(cuò)信息。當(dāng)在其他語言中創(chuàng)建一個(gè) Exception 消息時(shí)，你也可以遵循這個(gè)實(shí)踐。如果我們?cè)? viewUsers 處理中堅(jiān)持這點(diǎn)，那么幾乎總是能明確錯(cuò)誤的原因。

問題來自于那些不遵循這個(gè)***實(shí)踐的人，并且你經(jīng)常會(huì)在第三方的 Go 庫中看到這些消息：

Oh no I broke

這沒什么幫助 - 你無法了解上下文，這使得調(diào)試很困難。更糟糕的是，當(dāng)這些錯(cuò)誤被忽略或返回時(shí)，這些錯(cuò)誤會(huì)被備份到堆棧中，直到它們被處理為止：

if err != nil {
  return err
}

這意味著錯(cuò)誤何時(shí)發(fā)生并沒有被傳遞出來。

應(yīng)該注意的是，所有這些錯(cuò)誤都可以在 Exception 驅(qū)動(dòng)的模型中發(fā)生 - 糟糕的錯(cuò)誤信息、隱藏異常等。那么為什么我認(rèn)為該模型更有用?

即便我們?cè)谔幚硪粋€(gè)糟糕的異常消息，我們?nèi)匀荒軌蛄私馑l(fā)生在調(diào)用堆棧中什么地方。因?yàn)槎褩８?，這引發(fā)了一些我對(duì) Go 不了解的部分 - 你知道 Go 的 panic 包含了堆棧追蹤，但是 error 沒有。我推測(cè)可能是 panic 會(huì)使你的程序崩潰，因此需要一個(gè)堆棧追蹤，而處理錯(cuò)誤并不會(huì)，因?yàn)樗鼤?huì)假定你在它發(fā)生的地方做一些事。

所以讓我們回到之前的例子 - 一個(gè)有糟糕錯(cuò)誤信息的第三方庫，它只是輸出了調(diào)用鏈。你認(rèn)為調(diào)試會(huì)更容易嗎?

panic: Oh no I broke
[signal 0xb code=0x1 addr=0x0 pc=0xfc90f]
 
goroutine 1103 [running]:
panic(0x4bed00, 0xc82000c0b0)
/usr/local/go/src/runtime/panic.go:481 +0x3e6
github.com/Org/app/core.(_app).captureRequest(0xc820163340, 0x0, 0x55bd50, 0x0, 0x0)
/home/ubuntu/.go_workspace/src/github.com/Org/App/core/main.go:313 +0x12cf
github.com/Org/app/core.(_app).processRequest(0xc820163340, 0xc82064e1c0, 0xc82002aab8, 0x1)
/home/ubuntu/.go_workspace/src/github.com/Org/App/core/main.go:203 +0xb6
github.com/Org/app/core.NewProxy.func2(0xc82064e1c0, 0xc820bb2000, 0xc820bb2000, 0x1)
/home/ubuntu/.go_workspace/src/github.com/Org/App/core/proxy.go:51 +0x2a
github.com/Org/app/core/vendor/github.com/rusenask/goproxy.FuncReqHandler.Handle(0xc820da36e0, 0xc82064e1c0, 0xc820bb2000, 0xc5001, 0xc820b4a0a0)
/home/ubuntu/.go_workspace/src/github.com/Org/app/core/vendor/github.com/rusenask/goproxy/actions.go:19 +0x30

我認(rèn)為這可能是 Go 的設(shè)計(jì)中被忽略的東西 - 不是所有語言都不會(huì)忽視的。

如果我們使用 Java 作為一個(gè)隨意的例子，其中人們犯的一個(gè)最愚蠢的錯(cuò)誤是不記錄堆棧追蹤：

LOGGER.error(ex.getMessage()) // 不記錄堆棧追蹤
LOGGER.error(ex.getMessage(), ex) // 記錄堆棧追蹤

但是 Go 似乎在設(shè)計(jì)中就沒有這個(gè)信息。

在獲取上下文信息方面 - Russ 還提到了社區(qū)正在討論一些潛在的接口用于剝離上下文錯(cuò)誤。關(guān)于這點(diǎn)，了解更多或許會(huì)很有趣。

堆棧追蹤問題解決方案

幸運(yùn)的是，在做了一些查找后，我發(fā)現(xiàn)了這個(gè)出色的 Go 錯(cuò)誤庫來幫助解決這個(gè)問題，來給錯(cuò)誤添加堆棧跟蹤：

if errors.Is(err, crashy.Crashed) {
  fmt.Println(err.(*errors.Error).ErrorStack())
}

不過，我認(rèn)為這個(gè)功能如果能成為語言的***類公民first class citizenship將是一個(gè)改進(jìn)，這樣你就不必做一些類型修改了。此外，如果我們像先前的例子那樣使用第三方庫，它可能沒有使用 crashy - 我們?nèi)杂邢嗤膯栴}。

我們對(duì)錯(cuò)誤應(yīng)該做什么?

我們還必須考慮發(fā)生錯(cuò)誤時(shí)應(yīng)該發(fā)生什么。這一定有用，它們不會(huì)讓你的程序崩潰，通常也會(huì)立即處理它們：

err := method()
if err != nil {
  // some logic that I must do now in the event of an error!
}

如果我們想要調(diào)用大量方法，它們會(huì)產(chǎn)生錯(cuò)誤，然后在一個(gè)地方處理所有錯(cuò)誤，這時(shí)會(huì)發(fā)生什么?看上去像這樣：

err := doSomething()
if err != nil {
  // handle the error here
}
 
func doSomething() error {
  err := someMethod()
  if err != nil {
    return err
  }
  err = someOther()
  if err != nil {
    return err
  }
  someOtherMethod()
}

這感覺有點(diǎn)冗余，在其他語言中你可以將多條語句作為一個(gè)整體處理。

try {
  someMethod()
  someOther()
  someOtherMethod()
}
catch (Exception e) {
  // process exception
}

或者只要在方法簽名中傳遞錯(cuò)誤：

public void doSomething() throws SomeErrorToPropogate {
  someMethod()
  someOther()
  someOtherMethod()
}

我個(gè)人認(rèn)為這兩個(gè)例子實(shí)現(xiàn)了一件事情，只是 Exception 模式更少冗余，更加彈性。如果有什么的話，我覺得 if err!= nil 感覺像樣板。也許有一種方法可以清理?

將失敗的多條語句做為一個(gè)整體處理錯(cuò)誤

首先，我做了更多的閱讀，并在 Rob Pike 寫的 Go 博客中發(fā)現(xiàn)了一個(gè)比較務(wù)實(shí)的解決方案。

他定義了一個(gè)封裝了錯(cuò)誤的方法的結(jié)構(gòu)體：

type errWriter struct {
    w   io.Writer
    err error
}
 
func (ew *errWriter) write(buf []byte) {
    if ew.err != nil {
        return
    }
    _, ew.err = ew.w.Write(buf)
}

讓我們這么做：

ew := &errWriter{w: fd}
ew.write(p0[a:b])
ew.write(p1[c:d])
ew.write(p2[e:f])
// and so on
if ew.err != nil {
    return ew.err
}

這也是一個(gè)很好的方案，但是我感覺缺少了點(diǎn)什么 - 因?yàn)槲覀儾荒苤貜?fù)使用這個(gè)模式。如果我們想要一個(gè)含有字符串參數(shù)的方法，我們就不得不改變函數(shù)簽名?；蛘呷绻覀儾幌雸?zhí)行寫操作會(huì)怎樣?我們可以嘗試使它更通用：

type errWrapper struct {
    err error
}

func (ew *errWrapper) do(f func() error) {
    if ew.err != nil {
        return
    }
    ew.err = f();
}

但是我們有一個(gè)相同的問題，如果我們想要調(diào)用含有不同參數(shù)的函數(shù)，它就無法編譯了。然而你可以簡(jiǎn)單地封裝這些函數(shù)調(diào)用：

w := &errWrapper{}
 
w.do(func() error {
    return someFunction(1, 2);
})
 
w.do(func() error {
    return otherFunction("foo");
})
 
err := w.err
 
if err != nil {
// process error here
}

這可以用，但是并沒有太大幫助，因?yàn)樗罱K比標(biāo)準(zhǔn)的 if err != nil 檢查帶來了更多的冗余。如果有人能提供其他解決方案，我會(huì)很有興趣聽?；蛟S這個(gè)語言本身需要一些方法來以不那么臃腫的方式傳遞或者組合錯(cuò)誤 - 但是感覺似乎是特意設(shè)計(jì)成不那么做。

總結(jié)

看完這些之后，你可能會(huì)認(rèn)為我在對(duì) error 挑刺兒，由此推論我反對(duì) Go。事實(shí)并非如此，我只是將它與我使用 try catch 模型的經(jīng)驗(yàn)進(jìn)行比較。它是一個(gè)用于系統(tǒng)編程很好的語言，并且已經(jīng)出現(xiàn)了一些優(yōu)秀的工具。僅舉幾例，有 Kubernetes、Docker、Terraform、Hoverfly 等。還有小型、高性能、本地二進(jìn)制的優(yōu)點(diǎn)。但是，error 難以適應(yīng)。 我希望我的推論是有道理的，而且一些方案和解決方法可能會(huì)有幫助。