聊聊Golang飽受爭(zhēng)議的error

一、error是什么?
在C中,返回錯(cuò)誤通過(guò)errno.h中的錯(cuò)誤代碼來(lái)表示,比如0代表No error,也就是沒(méi)有錯(cuò)誤;2代表No such file or directory,也就是找不到指定路徑的文件或文件夾;5代表Input/Output error,表示輸入或輸出出現(xiàn)了錯(cuò)誤...

而在我們最?lèi)?ài)的Golang中,有這樣一個(gè)飽受爭(zhēng)議的error類(lèi)型,它不是一個(gè)整數(shù),而是一個(gè)接口。

package main

import (
    "errors"
    "fmt"
)

type name struct {
    error string
}

func (n *name) Error() string {
    return fmt.Sprintf("%s : ...", n.error)
}

func main() {
    
    err := judge(11)
    //err := judge(1)
    //err := judge(6)
    fmt.Println(err)
}

func judge(num int) error {
    if num > 5 && num < 10 {
        return errors.New("這個(gè)數(shù)字大于5了..")
    }
    if num >= 10 {
        return fmt.Errorf("%d大于或等于10了...", num)
    }
    return &name{error: "hello"}
}
這是三種可以作為error返回值的方式。errors.New()創(chuàng)建出來(lái)的error類(lèi)型其實(shí)是errorString結(jié)構(gòu)體。

// src/errors/errors.go

// New returns an error that formats as the given text.
// Each call to New returns a distinct error value even if the text is identical.
func New(text string) error {
 return &errorString{text}
}

// errorString is a trivial implementation of error.
type errorString struct {
 s string
}

func (e *errorString) Error() string {
 return e.s
}
所以我們創(chuàng)建的結(jié)構(gòu)體name其實(shí)和errors.New()底層的形式是基本一樣的。

而使用的fmt.Errorf其實(shí)是先將字符串格式化然后再調(diào)用errors.New()。

二、error引人爭(zhēng)論的點(diǎn)在哪?
在Go中,設(shè)計(jì)者從語(yǔ)言層面要求人們需要明確地處理遇到的錯(cuò)誤,但是因此導(dǎo)致的問(wèn)題也十分明顯,使用Go語(yǔ)言編寫(xiě)的代碼中err會(huì)到處都是,不過(guò)優(yōu)秀的IDE——Goland能夠解決這個(gè)問(wèn)題,使用Goland能夠?qū)rr!=nil這段判斷和處理壓縮,不再干擾代碼的閱讀。

我本人是不太喜歡Java的try-catch機(jī)制,可能是不太會(huì)用,Go語(yǔ)言官方提到try-catch會(huì)讓代碼變得比較混亂,很多程序員會(huì)胡亂catch異常,導(dǎo)致錯(cuò)誤處理比較冗長(zhǎng)。

而Go語(yǔ)言通過(guò)多返回值機(jī)制,讓返回錯(cuò)誤變得很簡(jiǎn)單,并且提供panic和error兩種機(jī)制,感覺(jué)這種機(jī)制更有優(yōu)勢(shì),也看起來(lái)更簡(jiǎn)潔。

煎魚(yú)大佬之前有博客談到了Go社區(qū)中關(guān)于Go錯(cuò)誤處理的新議題,大家想了解的可以看看:

Go 錯(cuò)誤處理新思路?用左側(cè)函數(shù)和表達(dá)式:https://juejin.cn/post/7102268049213882398
Go try 新提案靠譜嗎?想簡(jiǎn)化錯(cuò)誤處理了 https://juejin.cn/post/7157931922008571940
其實(shí)之前Go社區(qū)中出現(xiàn)過(guò)多種關(guān)于錯(cuò)誤處理的新議題,但是都沒(méi)有被采納...

三、如何優(yōu)雅的處理錯(cuò)誤
1. 避免處理“哨兵錯(cuò)誤”,即Sentinel errors
比如為了判斷err == io.EOF就得引入io包,這是標(biāo)準(zhǔn)庫(kù)的包還能接受,如果是第三方庫(kù)的包,并且使用“哨兵錯(cuò)誤”,很容易導(dǎo)致循環(huán)引用的問(wèn)題。

2. 避免使用error類(lèi)型
雖然這種錯(cuò)誤比“哨兵錯(cuò)誤”要好,它可以捕獲更多關(guān)于錯(cuò)誤的上下文信息,比如出錯(cuò)的行數(shù)等其他字段信息。但是又不可避免地在定義錯(cuò)誤和使用錯(cuò)誤的包之間形成依賴(lài)關(guān)系,又容易導(dǎo)致循環(huán)引用的問(wèn)題。

3. 使用不透明的“黑盒錯(cuò)誤”
func f() error{
    sentence,err := say.Hello()
    if err != nil{
        return err
    }
    // ...
}
上面這種寫(xiě)法是不是我們經(jīng)常會(huì)用到?這種情況下,我們只需要判斷err是否為空,不為空,代表有錯(cuò)誤,就直接返回錯(cuò)誤,否則就繼續(xù)執(zhí)行后面的流程。

作為程序執(zhí)行者,你沒(méi)有能力看到程序錯(cuò)誤的內(nèi)部信息,只能知道程序有錯(cuò)或者沒(méi)有錯(cuò)誤。這種錯(cuò)誤處理作為一種調(diào)試輔助手段還是不錯(cuò)的。

4. 使用Warp和Cause
第三方庫(kù)github.com/pkg/errors可以輸出錯(cuò)誤堆棧,并且使用起來(lái)很簡(jiǎn)單,大家可以了解一下。

// Wrap annotates cause with a message.
func Wrap(cause error, message string) error
// Cause unwraps an annotated error.
func Cause(err error) error
下面來(lái)介紹Wrap和Cause的使用樣例:

func ReadFile(path string) ([]byte, error) {
        f, err := os.Open(path)
        if err != nil {
                return nil, errors.Wrap(err, "open failed")
        }
        defer f.Close()

        buf, err := ioutil.ReadAll(f)
        if err != nil {
                return nil, errors.Wrap(err, "read failed")
        }
        return buf, nil
}

func ReadConfig() ([]byte, error) {
        home := os.Getenv("HOME")
        config, err := ReadFile(filepath.Join(home, ".settings.xml"))
        return config, errors.Wrap(err, "could not read config")
}

func main() {
        _, err := ReadConfig()
        if err != nil {
                fmt.Println(err)
                os.Exit(1)
        }
}
如果ReadConfig()執(zhí)行失敗,就會(huì)得到下面這一行十分美觀的報(bào)錯(cuò):

could not read config: open failed: open /Users/dfc/.settings.xml: no such file or directory
而如果用fmt.Printf和%+v格式來(lái)輸出就能看到更清晰、更有層次的錯(cuò)誤堆棧:

func main() {
        _, err := ReadConfig()
        if err != nil {
                fmt.Printf("%+v",err)
                os.Exit(1)
        }
}

然后我們?cè)賮?lái)看Cause的使用。

type temporary interface{
    Temporary() bool
}

// IsTemporary returns true if err is temporary.
func IsTemporary(err error) bool {
        te, ok := errors.Cause(err).(temporary)
        return ok && te.Temporary()
}
當(dāng)需要檢查一個(gè)錯(cuò)誤與一個(gè)特定的值或類(lèi)型時(shí)。比如此處,先用Cause取出錯(cuò)誤,做斷言,最后調(diào)用Temporary(),如果斷言失敗,ok就會(huì)是false,就不會(huì)調(diào)用右邊的Temporary()去執(zhí)行。

如果 && 運(yùn)算符左側(cè)的子表達(dá)式為 false,則不會(huì)檢查右側(cè)的表達(dá)式。因?yàn)橹灰幸粋€(gè)子表達(dá)式為 false,則整個(gè)表達(dá)式都為 false,所以再檢查剩余的表達(dá)式會(huì)浪費(fèi) CPU 時(shí)間。這被稱(chēng)為短路評(píng)估。



請(qǐng)前往:http://lygongshang.com/TeacherV2.html?id=365