Go語言的錯(cuò)誤處理方法有哪些

這篇文章主要介紹了Go語言的錯(cuò)誤處理方法有哪些的相關(guān)知識(shí)，內(nèi)容詳細(xì)易懂，操作簡(jiǎn)單快捷，具有一定借鑒價(jià)值，相信大家閱讀完這篇Go語言的錯(cuò)誤處理方法有哪些文章都會(huì)有所收獲，下面我們一起來看看吧。

與其他語言的快速比較

在 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ù))?！?/p>

這個(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 +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ì)中被忽略的東西 - 不是所有語言都不會(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 onif 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}

關(guān)于“Go語言的錯(cuò)誤處理方法有哪些”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對(duì)“Go語言的錯(cuò)誤處理方法有哪些”知識(shí)都有一定的了解，大家如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。