Golang 錯(cuò)誤處理最讓人頭疼的問題就是代碼里充斥著「if err != nil」炸宵，它們破壞了代碼的可讀性辟躏，本文收集了幾個(gè)例子，讓大家明白如何優(yōu)化此類問題土全。
讓我們看看 Errors are values 中提到的一個(gè) 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
}
如上代碼乍一看無法直觀的看出其本來的意圖是什么捎琐，改進(jìn)版：
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裹匙，新類型有一個(gè) write 方法瑞凑，不過其方法簽名并沒有返回 error，而是在方法內(nèi)部判斷一旦有問題就立刻返回概页，有了這些準(zhǔn)備工作籽御，我們就可以把原本穿插在業(yè)務(wù)邏輯中間的錯(cuò)誤判斷提出來放到最后來統(tǒng)一調(diào)用，從而在視覺上保證讓人可以直觀的看出代碼本來的意圖是什么。
讓我們?cè)倏纯?Eliminate error handling by eliminating errors 中提到的另一個(gè) 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
}
第一感覺既然錯(cuò)誤是 fmt.Fprint 和 io.Copy 返回的技掏，是不是我們要重新封裝一下它們铃将？實(shí)際上真正的源頭是它們的參數(shù) io.Writer，因?yàn)橹苯诱{(diào)用 io.Writer 的 Writer 方法的話哑梳，方法簽名中有返回值 error劲阎，所以每一步 fmt.Fprint 和 io.Copy 操作都不得不進(jìn)行重復(fù)的錯(cuò)誤處理，看上去是壞味道鸠真，改進(jìn)版：
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，同時(shí)重寫了 Writer 方法吠卷，雖然方法簽名中仍然有返回值 error锡垄，但是我們單獨(dú)保存了一份 error，并且在方法內(nèi)部判斷一旦有問題就立刻返回祭隔，有了這些準(zhǔn)備工作货岭，新版的 WriteResponse 不再有重復(fù)的錯(cuò)誤判斷，只需要在最后檢查一下 error 即可序攘。
類似的做法在 Golang 標(biāo)準(zhǔn)庫中屢見不鮮茴她，讓我們繼續(xù)看看 Eliminate error handling by eliminating errors 中提到的一個(gè)關(guān)于 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
}
我們構(gòu)造一個(gè) bufio.Reader寻拂，然后在一個(gè)循環(huán)中調(diào)用 ReadString 方法程奠，如果讀到文件結(jié)尾，那么 ReadString 會(huì)返回一個(gè)錯(cuò)誤（io.EOF）祭钉，為了判斷此類情況瞄沙，我們不得不在每次循環(huán)時(shí)判斷「if err != nil」，看上去這是壞味道慌核，改進(jìn)版：
func CountLines(r io.Reader) (int, error) {
sc := bufio.NewScanner(r)
lines := 0
for sc.Scan() {
lines++
}
return lines, sc.Err()
}
實(shí)際上距境，和 bufio.Reader 相比，bufio.Scanner 是一個(gè)更高階的類型垮卓，換句話簡(jiǎn)單點(diǎn)來說的話垫桂，相當(dāng)于是 bufio.Scanner 抽象了 bufio.Reader，通過把低階的 bufio.Reader 換成高階的 bufio.Scanner粟按，循環(huán)中不再需要判斷「if err != nil」诬滩，因?yàn)?Scan 方法簽名不再返回 error，而是返回 bool灭将，當(dāng)在循環(huán)里讀到了文件結(jié)尾的時(shí)候疼鸟，循環(huán)直接結(jié)束，如此一來庙曙，我們就可以統(tǒng)一在最后調(diào)用 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，和我們之前討論的做法一致吴攒。有一點(diǎn)說明一下张抄，實(shí)際上查看 Scan 源代碼的話，你會(huì)發(fā)現(xiàn)它不是通過 err 來判斷是否結(jié)束的洼怔，而是通過 done 來判斷是否結(jié)束欣鳖，這是因?yàn)?Scan 只有遇到文件結(jié)束的錯(cuò)誤才退出，其它錯(cuò)誤會(huì)繼續(xù)執(zhí)行茴厉，當(dāng)然泽台，這只是具體的細(xì)節(jié)問題，不影響我們的結(jié)論矾缓。
通過對(duì)以上幾個(gè)例子的分析怀酷，我們可以得出優(yōu)化重復(fù)錯(cuò)誤處理的大概套路：通過創(chuàng)建新的類型來封裝原本干臟活累活的舊類型，同時(shí)在新類型中封裝 error嗜闻，新舊類型的方法簽名可以保持兼容蜕依，也可以不兼容，這個(gè)不是關(guān)鍵的琉雳，視客觀情況而定样眠，至于具體的邏輯實(shí)現(xiàn)，先判斷有沒有 error翠肘，如果有就直接退出檐束，如果沒有就繼續(xù)執(zhí)行，并且在執(zhí)行過程中保存可能出現(xiàn)的 error 以便后面操作使用束倍，最后通過統(tǒng)一調(diào)用新類型的 error 來完成錯(cuò)誤處理被丧。提醒一下，此方案的缺點(diǎn)是要到最后才能知道有沒有錯(cuò)誤绪妹，好在如此的控制粒度在多數(shù)時(shí)候并無大礙甥桂。
