我對(duì)Go語(yǔ)言的錯(cuò)誤處理有哪些不滿，以及我是如何處理的
寫 Go 的人往往對(duì)它的錯(cuò)誤處理模式有一定的看法。按不同的語(yǔ)言經(jīng)驗(yàn)，人們可能有不同的習(xí)慣處理方法。這就是為什么我決定要寫這篇文章，盡管有點(diǎn)固執(zhí)己見(jiàn)，但我認(rèn)為聽(tīng)取我的經(jīng)驗(yàn)是有用的。我想要講的主要問(wèn)題是，很難去強(qiáng)制執(zhí)行良好的錯(cuò)誤處理實(shí)踐，錯(cuò)誤經(jīng)常沒(méi)有堆棧追蹤，并且錯(cuò)誤處理本身太冗長(zhǎng)。不過(guò)，我已經(jīng)看到了一些潛在的解決方案，或許能幫助解決一些問(wèn)題。
與其他語(yǔ)言的快速比較
在 Go 中，所有的錯(cuò)誤都是值。因?yàn)檫@點(diǎn)，相當(dāng)多的函數(shù)***會(huì)返回一個(gè) error, 看起來(lái)像這樣：
- func (s *SomeStruct) Function() (string, error)
因此這導(dǎo)致調(diào)用代碼通常會(huì)使用 if 語(yǔ)句來(lái)檢查它們：
bytes, err := someStruct.Function()if err != nil {// Process error}
另外一種方法，是在其他語(yǔ)言中，如 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 codeif err := userTemplate.Execute(w, user); err != nil {http.Error(w, err.Error(), 500)}}func viewCompanies(w http.ResponseWriter, r *http.Request) {companies = // some codeif err := companiesTemplate.Execute(w, companies); err != nil {http.Error(w, err.Error(), 500)}}
這并不是一個(gè)好的解決方案，因?yàn)槲覀儾坏貌恢貜?fù)地在所有的處理函數(shù)中處理錯(cuò)誤。為了能更好地維護(hù)，***能在一處地方處理錯(cuò)誤。幸運(yùn)的是，在 Go 語(yǔ)言的官方博客中，Andrew Gerrand 提供了一個(gè)替代方法，可以***地實(shí)現(xiàn)。我們可以創(chuàng)建一個(gè)處理錯(cuò)誤的 Type：
type appHandler func(http.ResponseWriter, *http.Request) errorfunc (fn appHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {if err := fn(w, r); err != nil {http.Error(w, err.Error(), 500)}}
這可以作為一個(gè)封裝器來(lái)修飾我們的處理函數(shù)：
func init() {http.Handle("/users", appHandler(viewUsers))http.Handle("/companies", appHandler(viewCompanies))}
接著我們需要做的是修改處理函數(shù)的簽名來(lái)使它們返回 errors。這個(gè)方法很好，因?yàn)槲覀冏龅搅?DRY 原則，并且沒(méi)有重復(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è)過(guò)程中，各種錯(cuò)誤可能在不同的地方實(shí)例化。Russ Cox的這篇文章解釋了如何避免遇到太多這類問(wèn)題的***實(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)在其他語(yǔ)言中創(chuàng)建一個(gè) Exception 消息時(shí)，你也可以遵循這個(gè)實(shí)踐。如果我們?cè)? viewUsers 處理中堅(jiān)持這點(diǎn)，那么幾乎總是能明確錯(cuò)誤的原因。
問(wèn)題來(lái)自于那些不遵循這個(gè)***實(shí)踐的人，并且你經(jīng)常會(huì)在第三方的 Go 庫(kù)中看到這些消息：
Oh no I broke
這沒(méi)什么幫助 - 你無(wú)法了解上下文，這使得調(diào)試很困難。更糟糕的是，當(dāng)這些錯(cuò)誤被忽略或返回時(shí)，這些錯(cuò)誤會(huì)被備份到堆棧中，直到它們被處理為止：
if err != nil {return err}
這意味著錯(cuò)誤何時(shí)發(fā)生并沒(méi)有被傳遞出來(lái)。
應(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 沒(méi)有。我推測(cè)可能是 panic 會(huì)使你的程序崩潰，因此需要一個(gè)堆棧追蹤，而處理錯(cuò)誤并不會(huì)，因?yàn)樗鼤?huì)假定你在它發(fā)生的地方做一些事。
所以讓我們回到之前的例子 - 一個(gè)有糟糕錯(cuò)誤信息的第三方庫(kù)，它只是輸出了調(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 +0x3e6github.com/Org/app/core.(_app).captureRequest(0xc820163340, 0x0, 0x55bd50, 0x0, 0x0)/home/ubuntu/.go_workspace/src/github.com/Org/App/core/main.go:313 +0x12cfgithub.com/Org/app/core.(_app).processRequest(0xc820163340, 0xc82064e1c0, 0xc82002aab8, 0x1)/home/ubuntu/.go_workspace/src/github.com/Org/App/core/main.go:203 +0xb6github.com/Org/app/core.NewProxy.func2(0xc82064e1c0, 0xc820bb2000, 0xc820bb2000, 0x1)/home/ubuntu/.go_workspace/src/github.com/Org/App/core/proxy.go:51 +0x2agithub.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ì)中被忽略的東西 - 不是所有語(yǔ)言都不會(huì)忽視的。
如果我們使用 Java 作為一個(gè)隨意的例子，其中人們犯的一個(gè)最愚蠢的錯(cuò)誤是不記錄堆棧追蹤：
LOGGER.error(ex.getMessage()) // 不記錄堆棧追蹤LOGGER.error(ex.getMessage(), ex) // 記錄堆棧追蹤
但是 Go 似乎在設(shè)計(jì)中就沒(méi)有這個(gè)信息。
在獲取上下文信息方面 - Russ 還提到了社區(qū)正在討論一些潛在的接口用于剝離上下文錯(cuò)誤。關(guān)于這點(diǎn)，了解更多或許會(huì)很有趣。
堆棧追蹤問(wèn)題解決方案
幸運(yùn)的是，在做了一些查找后，我發(fā)現(xiàn)了這個(gè)出色的 Go 錯(cuò)誤庫(kù)來(lái)幫助解決這個(gè)問(wèn)題，來(lái)給錯(cuò)誤添加堆棧跟蹤：
if errors.Is(err, crashy.Crashed) {fmt.Println(err.(*errors.Error).ErrorStack())}
不過(guò)，我認(rèn)為這個(gè)功能如果能成為語(yǔ)言的***類公民first class citizenship將是一個(gè)改進(jìn)，這樣你就不必做一些類型修改了。此外，如果我們像先前的例子那樣使用第三方庫(kù)，它可能沒(méi)有使用 crashy - 我們?nèi)杂邢嗤膯?wèn)題。
我們對(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()}
這感覺(jué)有點(diǎn)冗余，在其他語(yǔ)言中你可以將多條語(yǔ)句作為一個(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 模式更少冗余，更加彈性。如果有什么的話，我覺(jué)得 if err!= nil 感覺(jué)像樣板。也許有一種方法可以清理?
將失敗的多條語(yǔ)句做為一個(gè)整體處理錯(cuò)誤
首先，我做了更多的閱讀，并在 Rob Pike 寫的 Go 博客中發(fā)現(xiàn)了一個(gè)比較務(wù)實(shí)的解決方案。
他定義了一個(gè)封裝了錯(cuò)誤的方法的結(jié)構(gòu)體：
type errWriter struct {w io.Writererr 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 onif ew.err != nil {return ew.err}
這也是一個(gè)很好的方案，但是我感覺(jué)缺少了點(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è)相同的問(wèn)題，如果我們想要調(diào)用含有不同參數(shù)的函數(shù)，它就無(wú)法編譯了。然而你可以簡(jiǎn)單地封裝這些函數(shù)調(diào)用：
w := &errWrapper{}w.do(func() error {return someFunction(1, 2);})w.do(func() error {return otherFunction("foo");})err := w.errif err != nil {// process error here}
這可以用，但是并沒(méi)有太大幫助，因?yàn)樗罱K比標(biāo)準(zhǔn)的 if err != nil 檢查帶來(lái)了更多的冗余。如果有人能提供其他解決方案，我會(huì)很有興趣聽(tīng)。或許這個(gè)語(yǔ)言本身需要一些方法來(lái)以不那么臃腫的方式傳遞或者組合錯(cuò)誤 - 但是感覺(jué)似乎是特意設(shè)計(jì)成不那么做。
總結(jié)
看完這些之后，你可能會(huì)認(rèn)為我在對(duì) error 挑刺兒，由此推論我反對(duì) Go。事實(shí)并非如此，我只是將它與我使用 try catch 模型的經(jīng)驗(yàn)進(jìn)行比較。它是一個(gè)用于系統(tǒng)編程很好的語(yǔ)言，并且已經(jīng)出現(xiàn)了一些優(yōu)秀的工具。僅舉幾例，有 Kubernetes、Docker、Terraform、Hoverfly 等。還有小型、高性能、本地二進(jìn)制的優(yōu)點(diǎn)。但是，error 難以適應(yīng)。 我希望我的推論是有道理的，而且一些方案和解決方法可能會(huì)有幫助。
