前言

上文我們了解了 Error 在 Go 中的設(shè)計(jì)理念。單從理念上來看， Error 的設(shè)計(jì)似乎有利于邏輯處理。但實(shí)際上，在開發(fā)過程中，我們還會(huì)遇到各種各樣的困難。為了優(yōu)化開發(fā)的流程，開發(fā)者們發(fā)明了很多處理 Error 的做法。今天我們就來看看目前 Go 開發(fā)中常見的幾大 Error 類型。

透明錯(cuò)誤處理策略

在最簡(jiǎn)單的 Go Error 設(shè)計(jì)中，開發(fā)者被期望通過判定函數(shù)返回的 err 值來確定調(diào)用是否正常。

value, err := doSomething()
if err != nil {
	// 錯(cuò)誤處理
}
// 邏輯操作

這是 Go 語言中最常見的錯(cuò)誤處理策略 ，80%以上的 Go 錯(cuò)誤處理情形都可以歸類到這種策略下。這樣構(gòu)造出的錯(cuò)誤值代表的上下文信息，對(duì)錯(cuò)誤處理方是透明的，因此這種策略稱為 透明錯(cuò)誤處理策略 。

這種策略最大的問題是，無法判定錯(cuò)誤的原因和種類。它只是簡(jiǎn)單地把”是否出錯(cuò)“分為了兩路邏輯。一旦我們的業(yè)務(wù)要求我們針對(duì)不同的錯(cuò)誤原因，做不同的處理，這種情況就行不通了。

帶來的問題

透明策略只解決了”是否出錯(cuò)“的問題，但開發(fā)者無法知道錯(cuò)誤的原因。如果想要得到錯(cuò)誤的內(nèi)容，需要主動(dòng)解析error值，這也引出了下面要講的處理策略。

哨兵(Sentinel)錯(cuò)誤處理策略

哨兵策略策略主要是解決透明錯(cuò)誤處理策略精度不夠的情況，它可以讓開發(fā)者得到“是什么錯(cuò)誤”，而不僅是”是否出錯(cuò)“。實(shí)際上，它就是通過預(yù)定義錯(cuò)誤類型，在錯(cuò)誤處理時(shí)，判斷錯(cuò)誤是否屬于預(yù)定義的類別，從而做出處理。

因此我們可以得到它最簡(jiǎn)單的實(shí)現(xiàn)：

value, err := doSomething()
if err!=nil { 
    // 通過err.Error()獲得錯(cuò)誤信息
    switch err.Error(){ 
        case "bufio: negative count": 
        	//特點(diǎn)錯(cuò)誤處理 
        	return 
        // 其他判斷
        default: 
        	// 未知錯(cuò)誤原因
        	return 
    } 
}

但這顯然不是好的寫法，會(huì)導(dǎo)致很嚴(yán)重的耦合問題。Go 1.13 之后，我們可以用 error.Is 方法很好地解決這個(gè)問題。

// 定義錯(cuò)誤類型，一般變量用Err開頭
var(
  ErrInvalidUnreadByte=errors.New("bufio: invalid use of UnreadByte")ErrInvalidUnreadRune=errors.New("bufio: invalid use of UnreadRune")
  ErrBufferFull=errors.New("bufio: buffer full")
  ErrNegativeCount=errors.New("bufio: negative count")
)

func main(){
	value, err := doSomething()
  	if errors.Is(err,ErrBufferFull){
    	//判斷是否為某類型錯(cuò)誤
  	}
}

帶來的問題

雖然哨兵策略解決了我們不能獲得錯(cuò)誤原因的問題，但它本身也存在著設(shè)計(jì)缺陷。

1.對(duì)errors.Error()的依賴

== 的判斷依賴著 errors.Error() 的輸出。這是哨兵策略最大的問題。他導(dǎo)致了 error 值的擴(kuò)展性很差，假如開發(fā)者想要為 error 帶上上下文或者錯(cuò)誤行號(hào)，文件位置等信息，都會(huì)破壞哨兵策略的判斷。

從某種角度來看，errors.Error() 的輸出更應(yīng)該是用于開發(fā)者的調(diào)試使用，而不應(yīng)該作為程序判斷機(jī)制的一部分。

2.定義的錯(cuò)誤類型會(huì)被公開

很多時(shí)候?yàn)榱俗鲥e(cuò)誤類型判斷，一些包內(nèi)需要定義許多錯(cuò)誤類型。而這些錯(cuò)誤類型通常會(huì)被共用，這使得他們不得不被公開。在公共庫中，被公開的錯(cuò)誤類型必須有專門的文檔說明，否則會(huì)對(duì)使用者造成困惑。這會(huì)額外增加開發(fā)者的工作量。

再者，有時(shí)為了判斷某個(gè)特殊錯(cuò)誤類型，使用者會(huì)引入對(duì)應(yīng)的包。假如這種情況大量存在，會(huì)導(dǎo)致整個(gè)庫生態(tài)極其混亂。

Error types

Error types 是實(shí)現(xiàn)了 errors 接口的自定義類型，目的是為了更加具體地描述錯(cuò)誤。開發(fā)者可以在類型上帶上需要的信息，如行號(hào)，文件位置等?？梢詤⒖枷路剑?/p>

type MyError struct {
    Msg string	// 錯(cuò)誤信息
    Line int	// 行號(hào)
    FIle string // 文件位置
}

// 實(shí)現(xiàn) errors 接口
func (e *MyError) Error()string{
    return fmt.Sprintf("%s:%d: %s",e.File,e.Line,e.Msg)
}
    

上面提到，修改 error 值會(huì)導(dǎo)致哨兵策略的失效， Error types 就是例子之一。由于是自定義的類型，我們不能再用 == 判斷錯(cuò)誤類型了，而是改用斷言。

value, ok := x.(MyError)
if ok {
    //判斷是否為某類型錯(cuò)誤
}

帶來的問題

可以看到 Error Types 最大的優(yōu)勢(shì)是其豐富的錯(cuò)誤描述能力。但它仍然沒有解決哨兵策略下的問題。

不透明錯(cuò)誤處理策略(Opaque errors)

不透明錯(cuò)誤處理策略可以說是最靈活的處理方式，它要求代碼與調(diào)用者之間的耦合最少。開發(fā)者可以知道”是否出錯(cuò)“，但無法得到錯(cuò)誤的內(nèi)部信息。

value, err := doSomething()
if err != nil {
	// 錯(cuò)誤處理
}
// 邏輯操作

是的，在使用上不透明策略跟透明策略是很相似的。其中最大的不同是，透明策略可以通過 error.Error() 接口獲得錯(cuò)誤信息。而不透明策略中是不可以的。

那如果開發(fā)者需要判斷錯(cuò)誤類型怎么辦呢？不透明策略更推薦的是斷言 error 實(shí)現(xiàn)的行為，而不是特定的類型或值?？梢詤⒖枷路酱a：

type temporary interface {
    Temporary() bool
}
// 封裝判斷函數(shù)
func IsTemporary(err error) bool {
    // 斷言
    te, ok := err.(temporay)
    // 是否滿足條件
    return ok && te.Temporary()
}

帶來的問題

不透明策略跟透明策略一樣，是很靈活的策略。他們的區(qū)別只在于錯(cuò)誤的信息是否開放。因此，不透明策略依舊存在信息量缺乏的問題。

總結(jié)

今天我們了解了目前 Go 開發(fā)中常見的四種 Error 類型。這些類型各有優(yōu)劣，需要開發(fā)者在實(shí)際開發(fā)者中深入思考，做出取舍。通常我們需要考慮，我們開發(fā)的是工具還是業(yè)務(wù)，我們需要錯(cuò)誤為我們提供靈活度還是精確的信息。掌握本文的內(nèi)容，可以讓你在遇到錯(cuò)誤處理時(shí)，有更多的處理思路。

當(dāng)然，每種方式又會(huì)有問題，在接下來的文章里，我會(huì)分享一些常見的錯(cuò)誤處理操作。

以上就是Go語音開發(fā)中常見Error類型處理示例詳解的詳細(xì)內(nèi)容，更多關(guān)于Go語音Error類型的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論