[TOC] # error 返回低級錯誤,不想讓程序崩潰 go引入了一個錯誤處理的標準模式,是error接口,它是go語言內建的接口類型,該接口的定義如下 ~~~ type error interface { Error() string } ~~~ go標準庫代碼包errors為用戶提供如下的方法 ~~~ package errors type errorString struct { text string } func New(text string) error { return &errorString{text} } func (e *errorString) Error() string { return e.text } ~~~ 另一個可以生成error類型值的方法是調用fmt包中的Errorf函數 ~~~ package fmt import "errors" func Errorf(format string, args ...interface{}) error { return errors.New(Sprintf(format, args)) } ~~~ ## 使用 ~~~ func main() { var err error = fmt.Errorf("%s", "this is normal err") fmt.Println(err) var err1 error = errors.New("a normal err1") fmt.Println(err1) } ~~~ ## 應用 ~~~ func test(a, b int) (result int, err error) { if b == 0 { err = errors.New("分母不能為0") } else { result = a / b } return } func main() { result, err := test(10, 2) if err != nil { fmt.Println(err) } else { fmt.Println(result) } } ~~~ ## 類型 類型在已知范圍內的錯誤值其實是最容易分辨的。就拿os包中的幾個代表錯誤的類型os.PathError、os.LinkError、os.SyscallError和os/exec.Error來說，它們的指針類型都是error接口的實現類型，同時它們也都包含了一個名叫Err，類型為error接口類型的代表潛在錯誤的字段。 如果我們得到一個error類型值，并且知道該值的實際類型肯定是它們中的某一個，那么就可以用類型switch語句去做判斷。例如 ~~~ func underlyingError(err error) error { switch err := err.(type) { case *os.PathError: return err.Err case *os.LinkError: return err.Err case *os.SyscallError: return err.Err case *exec.Error: return err.Err } return err } ~~~ 我們還拿os包來說，其中不少的錯誤值都是通過調用errors.New函數來初始化的，比如：os.ErrClosed、os.ErrInvalid以及os.ErrPermission，等等 好在我們總是能通過錯誤值的Error方法，拿到它的錯誤信息。其實os包中就有做這種判斷的函數，比如：os.IsExist、os.IsNotExist和os.IsPermission # 根據實際情況給予恰當的錯誤值？ 我們已經知道，構建錯誤值體系的基本方式有兩種，即：創建立體的錯誤類型體系和創建扁平的錯誤值列表。 先說錯誤類型體系。由于在 Go 語言中實現接口是非侵入式的，所以我們可以做得很靈活。比如，在標準庫的net代碼包中，有一個名為Error的接口類型。它算是內建接口類型error的一個擴展接口，因為error是net.Error的嵌入接口。 net.Error接口除了擁有error接口的Error方法之外，還有兩個自己聲明的方法：Timeout和Temporary。 net包中有很多錯誤類型都實現了net.Error接口，比如： 1. \*net.OpError； 2. \*net.AddrError； 3. net.UnknownNetworkError等等。 你可以把這些錯誤類型想象成一棵樹，內建接口error就是樹的根，而net.Error接口就是一個在根上延伸的第一級非葉子節點。 同時，你也可以把這看做是一種多層分類的手段。當net包的使用者拿到一個錯誤值的時候，可以先判斷它是否是net.Error類型的，也就是說該值是否代表了一個網絡相關的錯誤。 如果是，那么我們還可以再進一步判斷它的類型是哪一個更具體的錯誤類型，這樣就能知道這個網絡相關的錯誤具體是由于操作不當引起的，還是因為網絡地址問題引起的，又或是由于網絡協議不正確引起的。 當我們細看net包中的這些具體錯誤類型的實現時，還會發現，與os包中的一些錯誤類型類似，它們也都有一個名為Err、類型為error接口類型的字段，代表的也是當前錯誤的潛在錯誤。 所以說，這些錯誤類型的值之間還可以有另外一種關系，即：鏈式關系。比如說，使用者調用net.DialTCP之類的函數時，net包中的代碼可能會返回給他一個\*net.OpError類型的錯誤值，以表示由于他的操作不當造成了一個錯誤。 同時，這些代碼還可能會把一個\*net.AddrError或net.UnknownNetworkError類型的值賦給該錯誤值的Err字段，以表明導致這個錯誤的潛在原因。如果，此處的潛在錯誤值的Err字段也有非nil的值，那么將會指明更深層次的錯誤原因。如此一級又一級就像鏈條一樣最終會指向問題的根源。