復(fù)習(xí)語(yǔ)法

在 2018 年 8 月，官方正式公布了 Go 2 Draft Designs[2]，其中包含泛型和錯(cuò)誤處理機(jī)制改進(jìn)的初步草案：

Go 2 Draft Designs

下面是關(guān)鍵的 Go2 錯(cuò)誤處理新語(yǔ)法。

錯(cuò)誤處理（Error Handling）

第一個(gè)要解決的問(wèn)題就是大量 if err != nil 的問(wèn)題，針對(duì)此提出了 Go2 error handling[3] 的草案設(shè)計(jì)。

簡(jiǎn)單例子：

if err != nil {
 return err
}

優(yōu)化后的方案如下：

func CopyFile(src, dst string) error {
 handle err {
  return fmt.Errorf("copy %s %s: %v", src, dst, err)
 }

 r := check os.Open(src)
 defer r.Close()

 w := check os.Create(dst)
 handle err {
  w.Close()
  os.Remove(dst) // (only if a check fails)
 }

 check io.Copy(w, r)
 check w.Close()
 return nil
}

主函數(shù)：

func main() {
 handle err {
  log.Fatal(err)
 }

 hex := check ioutil.ReadAll(os.Stdin)
 data := check parseHexdump(string(hex))
 os.Stdout.Write(data)
}

該提案引入了兩種新的語(yǔ)法形式，首先是 check? 關(guān)鍵字，其可以選中一個(gè)表達(dá)式 check f(x, y, z)? 或 check err，其將會(huì)標(biāo)識(shí)這是一個(gè)顯式的錯(cuò)誤檢查。

其次引入了 handle? 關(guān)鍵字，用于定義錯(cuò)誤處理程序流轉(zhuǎn)，逐級(jí)上拋，依此類(lèi)推，直到處理程序執(zhí)行 return 語(yǔ)句，才正式結(jié)束。

錯(cuò)誤值打印（Error Printing）

第二個(gè)要解決的問(wèn)題是錯(cuò)誤值（Error Values）、錯(cuò)誤檢查（Error Inspection）的問(wèn)題，其引申出錯(cuò)誤值打?。‥rror Printing）的問(wèn)題，也可以認(rèn)為是錯(cuò)誤格式化的不便利。

官方針對(duì)此提出了提出了 Error Values[4] 和 Error Printing[5] 的草案設(shè)計(jì)。

簡(jiǎn)單例子如下：

if err != nil {
 return fmt.Errorf("write users database: %v", err)
}

優(yōu)化后的方案如下：

package errors

type Wrapper interface {
 Unwrap() error
}

func Is(err, target error) bool
func As(type E)(err error) (e E, ok bool)

該提案增加了錯(cuò)誤鏈的 Wrapping Error 概念，并同時(shí)增加 errors.Is? 和 errors.As 的方法，與前面說(shuō)到的 Go1.13 的改進(jìn)一致，不再贅述。

Go1.13 沒(méi)有實(shí)現(xiàn) %+v 輸出調(diào)用堆棧的需求（沒(méi)有調(diào)用棧，排查問(wèn)題會(huì)很苦惱），因?yàn)榇伺e會(huì)破壞 Go1 兼容性和產(chǎn)生一些性能問(wèn)題，大概會(huì)在 Go2 加入。

對(duì)提案批判

目標(biāo)較為模糊

在 Go2 新錯(cuò)誤處理的提案和草案中，@Liam Breck 認(rèn)為其沒(méi)有去討論根本的需求。僅有一個(gè)簡(jiǎn)短的目標(biāo)部分，如下四點(diǎn)：

• 占用空間小的錯(cuò)誤檢查。
• 對(duì)開(kāi)發(fā)人員友好的錯(cuò)誤處理。
• 顯式檢查和處理錯(cuò)誤。
• 保證現(xiàn)有 Go1 代碼的兼容性。

更也沒(méi)有提到未來(lái)可能的擴(kuò)展性，只是純粹的滿足當(dāng)下的訴求。這類(lèi)是模糊的，在激發(fā)新的設(shè)計(jì)思路上有局限性。

無(wú)法統(tǒng)一錯(cuò)誤處理

在真實(shí)的應(yīng)用中，一個(gè)函數(shù)使用兩種及以上的重復(fù)錯(cuò)誤處理方式是非常常見(jiàn)的。

如下代碼：

// 方式 1
{ debug.PrintStack(); log.Fatal(err) }

// 方式 2
{ log.Println(err) }

// 方式 3
{ if err == io.EOF { break } }

// 方式 4
{ conn.Write([]byte("oops: " + err.Error())) } // network server

新提案中，check 和 handle 函數(shù)并不提供多種處理錯(cuò)誤的途徑。這是一個(gè)明顯的遺漏，也沒(méi)法統(tǒng)一錯(cuò)誤處理機(jī)制。

如此的話，check 和 handle 就完全是只加了一種新的方式，讓原本的錯(cuò)誤處理機(jī)制更加的繁雜。

混用 err != nil 和 check

handle 函數(shù)是后進(jìn)先出的模式，只能從一個(gè)函數(shù)中跳出。也就是說(shuō)它不能很友好的處理可恢復(fù)的錯(cuò)誤內(nèi)容。

但實(shí)際上，許多方法返回錯(cuò)誤是很常見(jiàn)的。因此我們需要同時(shí)使用 err!= nil 和 check，顯得非常的繁瑣。

如下代碼：

handle err { ... }
v, err := f()
if err != nil {
   if isBad(err) {
      check err
   }
   // recovery code
}

又是 if err != nil，又是 handle，又是 check 函數(shù)。

嵌套 check 更復(fù)雜

通過(guò) check 函數(shù)，對(duì)返回錯(cuò)誤的函數(shù)調(diào)用進(jìn)行嵌套調(diào)用，將會(huì)模糊了操作的順序。

雖然在大多數(shù)情況下，錯(cuò)誤發(fā)生時(shí)的調(diào)用順序應(yīng)該是清楚的，但在 check 函數(shù)下會(huì)顯得不如 if err != nil 清晰。

如下代碼：

check step4(check step1(), check step3(check step2())

另外嵌套代碼會(huì)助長(zhǎng)不可讀的結(jié)構(gòu)：

f1(v1, check f2(check f3(check f4(v4), v3), check f5(v5))

現(xiàn)在回顧一下，該語(yǔ)言禁止。

f(t ? a : b) 和 f(a++)

是不是顯得有些諷刺呢？

if err != nil 太好用

Go1 的錯(cuò)誤處理程序太友好了，也就是：

if err != nil {
    ...
}

其挫敗了 "提高開(kāi)發(fā)人員編寫(xiě)錯(cuò)誤處理程序的可能性" 的目標(biāo)，它使得在沒(méi)有上下文信息的情況下返回錯(cuò)誤是很容易的。會(huì)降低對(duì) handle、check 函數(shù)的使用頻率，變成一個(gè)可有可無(wú)的東西。

注：個(gè)人感覺(jué)，這一點(diǎn)既像黑又像粉...原作者反串黑？當(dāng)然，確實(shí) if err != nil 很好上手。

復(fù)雜的錯(cuò)誤鏈

對(duì)于下面的例子，看看它的感覺(jué)...

如下代碼：

func f() error {
   handle err { return ... }           // finally this
   if ... {
      handle err { ... }               // not that
      for ... {
         handle err { ... }            // nor that
         ...
      }
   }
   handle err { ... }                  // secondly this
   ...
   if ... {
      handle err { ... }               // not that
      ...
   } else {
      handle err { ... }               // firstly this
      check thisFails()                // trigger
   }
}

顯然，這段代碼是 “難以捉摸” 的，我們必須用眼睛解析整個(gè)函數(shù)，理解整個(gè)錯(cuò)誤處理的流程和順序。

將會(huì)加大我們對(duì)程序的認(rèn)知負(fù)擔(dān)。

總結(jié)

通過(guò)對(duì) Go2 錯(cuò)誤處理的設(shè)計(jì)草案的復(fù)習(xí)，我們了解到了 check 和 handle 函數(shù)的用法和思路。再針對(duì)新的語(yǔ)法，又對(duì)可能發(fā)生的新問(wèn)題進(jìn)行了 “批判”。

總的來(lái)說(shuō)，新的語(yǔ)法，在弊端上會(huì)增加既有的代碼復(fù)雜度和可讀性，可以引發(fā)各種奇怪的嵌套，還會(huì)與 if err != nil 產(chǎn)生重復(fù)，變成了一種新的處理方式（多了一種）。

是否會(huì)還不如 if err != nil 那么的純粹？

參考資料

[1]Golang, how dare you handle my checks!: 

[2]Go 2 Draft Designs: https://go.googlesource.com/proposal/+/master/design/go2draft.md

[3]Go2 error handling: https://github.com/golang/proposal/blob/master/design/go2draft-error-handling-overview.md

[4]Error Values: https://github.com/golang/proposal/blob/master/design/go2draft-error-values-overview.md

[5]Error Printing: https://github.com/golang/proposal/blob/master/design/go2draft-error-printing.md