Golang中重複錯誤處理的優化方法

這篇文章主要給大家介紹了關於Golang中重複錯誤處理優化的相關資料,文中通過示例代碼介紹的非常詳細,對大家學習或者使用Golang具有一定的參考學習價值,需要的朋友們下面來一起學習學習吧

Golang 錯誤處理最讓人頭疼的問題就是代碼裏充斥着「if err != nil」,它們破壞了代碼的可讀性,本文收集了幾個例子,讓大家明白如何優化此類問題。

讓我們看看 Errors are values 中提到的一個 io.Writer 例子:

_, err = fd.Write(p0[a:b])
if err != nil {
 return err
}
_, err = fd.Write(p1[c:d])
if err != nil {
 return err
}
_, err = fd.Write(p2[e:f])
if err != nil {
 return err
}

如上代碼乍一看無法直觀的看出其本來的意圖是什麼,改進版:

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])
if ew.err != nil {
 return ew.err
}

通過自定義類型 errWriter 來封裝 io.Writer,並且封裝了 error,新類型有一個 write 方法,不過其方法簽名並沒有返回 error,而是在方法內部判斷一旦有問題就立刻返回,有了這些準備工作,我們就可以把原本穿插在業務邏輯中間的錯誤判斷提出來放到最後來統一調用,從而在視覺上保證讓人可以直觀的看出代碼本來的意圖是什麼。

讓我們再看看 Eliminate error handling by eliminating errors 中提到的另一個 io.Writer 例子:

type Header struct {
 Key, Value string
}

type Status struct {
 Code int
 Reason string
}

func WriteResponse(w io.Writer, st Status, headers []Header, body io.Reader) error {
 _, err := fmt.Fprintf(w, "HTTP/1.1 %d %s\r\n", st.Code, st.Reason)
 if err != nil {
 return err
 }

 for _, h := range headers {
 _, err := fmt.Fprintf(w, "%s: %s\r\n", h.Key, h.Value)
 if err != nil {
 return err
 }
 }

 if _, err := fmt.Fprint(w, "\r\n"); err != nil {
 return err
 }

 _, err = io.Copy(w, body)
 return err
}

第一感覺既然錯誤是 fmt.Fprint 和 io.Copy 返回的,是不是我們要重新封裝一下它們?實際上真正的源頭是它們的參數 io.Writer,因爲直接調用 io.Writer 的 Writer 方法的話,方法簽名中有返回值 error,所以每一步 fmt.Fprint 和 io.Copy 操作都不得不進行重複的錯誤處理,看上去是壞味道,改進版:

type errWriter struct {
 io.Writer
 err error
}

func (e *errWriter) Write(buf []byte) (int, error) {
 if e.err != nil {
 return 0, e.err
 }

 var n int
 n, e.err = e.Writer.Write(buf)
 return n, nil
}

func WriteResponse(w io.Writer, st Status, headers []Header, body io.Reader) error {
 ew := &errWriter{Writer: w}
 fmt.Fprintf(ew, "HTTP/1.1 %d %s\r\n", st.Code, st.Reason)

 for _, h := range headers {
 fmt.Fprintf(ew, "%s: %s\r\n", h.Key, h.Value)
 }

 fmt.Fprint(ew, "\r\n")
 io.Copy(ew, body)

 return ew.err
}

通過自定義類型 errWriter 來封裝 io.Writer,並且封裝了 error,同時重寫了 Writer 方法,雖然方法簽名中仍然有返回值 error,但是我們單獨保存了一份 error,並且在方法內部判斷一旦有問題就立刻返回,有了這些準備工作,新版的 WriteResponse 不再有重複的錯誤判斷,只需要在最後檢查一下 error 即可。

類似的做法在 Golang 標準庫中屢見不鮮,讓我們繼續看看 Eliminate error handling by eliminating errors 中提到的一個關於 bufio.Reader 和 bufio.Scanner 的例子:

func CountLines(r io.Reader) (int, error) {
 var (
 br = bufio.NewReader(r)
 lines int
 err error
 )

 for {
 _, err = br.ReadString('\n')
 lines++
 if err != nil {
 break
 }
 }

 if err != io.EOF {
 return 0, err
 }

 return lines, nil
}

我們構造一個 bufio.Reader,然後在一個循環中調用 ReadString 方法,如果讀到文件結尾,那麼 ReadString 會返回一個錯誤(io.EOF),爲了判斷此類情況,我們不得不在每次循環時判斷「if err != nil」,看上去這是壞味道,改進版:

func CountLines(r io.Reader) (int, error) {
 sc := bufio.NewScanner(r)
 lines := 0

 for sc.Scan() {
 lines++
 }

 return lines, sc.Err()
}

實際上,和 bufio.Reader 相比,bufio.Scanner 是一個更高階的類型,換句話簡單點來說的話,相當於是 bufio.Scanner 抽象了 bufio.Reader,通過把低階的 bufio.Reader 換成高階的 bufio.Scanner,循環中不再需要判斷「if err != nil」,因爲 Scan 方法簽名不再返回 error,而是返回 bool,當在循環裏讀到了文件結尾的時候,循環直接結束,如此一來,我們就可以統一在最後調用 Err 方法來判斷成功還是失敗,看看 Scanner 的定義:

type Scanner struct {
 r   io.Reader // The reader provided by the client.
 split  SplitFunc // The function to split the tokens.
 maxTokenSize int  // Maximum size of a token; modified by tests.
 token  []byte // Last token returned by split.
 buf   []byte // Buffer used as argument to split.
 start  int  // First non-processed byte in buf.
 end   int  // End of data in buf.
 err   error  // Sticky error.
 empties  int  // Count of successive empty tokens.
 scanCalled bool  // Scan has been called; buffer is in use.
 done   bool  // Scan has finished.
}

可見 Scanner 封裝了 io.Reader,並且封裝了 error,和我們之前討論的做法一致。有一點說明一下,實際上查看 Scan 源代碼的話,你會發現它不是通過 err 來判斷是否結束的,而是通過 done 來判斷是否結束,這是因爲 Scan 只有遇到文件結束的錯誤才退出,其它錯誤會繼續執行,當然,這只是具體的細節問題,不影響我們的結論。

通過對以上幾個例子的分析,我們可以得出優化重複錯誤處理的大概套路:通過創建新的類型來封裝原本幹髒活累活的舊類型,同時在新類型中封裝 error,新舊類型的方法簽名可以保持兼容,也可以不兼容,這個不是關鍵的,視客觀情況而定,至於具體的邏輯實現,先判斷有沒有 error,如果有就直接退出,如果沒有就繼續執行,並且在執行過程中保存可能出現的 error 以便後面操作使用,最後通過統一調用新類型的 error 來完成錯誤處理。提醒一下,此方案的缺點是要到最後才能知道有沒有錯誤,好在如此的控制粒度在多數時候並無大礙。

總結

以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,謝謝大家對神馬文庫的支持。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章