golang怎麼進行錯誤處理

Golang通常有三種錯誤處理方式：錯誤哨兵（Sentinel Error）、錯誤類型斷言和記錄錯誤呼叫堆疊。錯誤哨兵指的是用特定值的變數作為錯誤處理分支的判定條件。錯誤類型用於路由錯誤處理邏輯，和錯誤哨兵有異曲同工的作用，由類型系統來提供錯誤種類的唯一性。錯誤黑盒指的是不過度關心錯誤類型，將錯誤傳回給上層；當需要採取行動時，要針對錯誤的行為進行斷言，而非錯誤類型。

本教學操作環境：windows7系統、GO 1.18版本、Dell G3電腦。

golang沒有提供try-catch類似的錯誤處理機制，在設計層面採用了C語言風格的錯誤處理，透過函數傳回值傳回出錯的錯誤訊息，具體樣例如下：

func ReturnError() (string, error) {
	return "", fmt.Errorf("Test Error")
}

func main() {
	val, err := ReturnError()
	if err != nil {
		panic(err)
	}
	fmt.Println(val)
}

上面的例子是一個基本的錯誤處理樣例，生產環境中執行的調用棧往往非常複雜，返回的error也各式各樣，常常需要根據返回的錯誤訊息確定具體的錯誤處理邏輯。

Golang通常有以下的三種錯誤處理方式，錯誤哨兵(Sentinel Error)、錯誤類型斷言(Error Type Asseration)和記錄錯誤呼叫堆疊。

錯誤哨兵(Sentinel Error)

哨兵指的是用特定值的變數作為錯誤處理分支的判定條件，常見的應用場景有gorm中的gorm.RecordNotFounded和redis庫裡的redis.NIL。

golang裡可以對同類型變數進行比較，介面變數則比較介面指向的的指標的位址。因此，當且僅當error類型的變數指向相同位址時，此兩個變數相等，否則皆為不相等。

var ErrTest = errors.New("Test Error")

err := doSomething()
if err == ErrTest{
	// TODO: Do With Error
}

使用哨兵存在以下幾個問題有兩個問題：

1、程式碼結構不靈活，分支處理只能使用==或! =進行判定，長此以往，容易寫出常義大利麵式的程式碼。

var ErrTest1 = errors.New("ErrTest1")
var ErrTest2 = errors.New("ErrTest1")
var ErrTest3 = errors.New("ErrTest1")
……
var ErrTestN = errors.New("ErrTestN")
……
if err  == ErrTest1{
	……
} else if err == ErrTest2{
	……
}else if err == ErrTest3{
	……
}
……
else err == ErrTestN{
	……
}

2、哨兵變數值不能被修改，否則會導致邏輯錯誤，上述golang寫法的error哨兵可以被改變，可以透過以下方式解決：

type Error string

func (e Error) Error() string { return string(e) }

3、哨兵變數會導致極強的耦合性，介面新增error的吐出就會造成使用者對應修改程式碼新增處理錯誤的問題。

比較上面的方案，錯誤哨兵還有一個更優雅的方案，依賴介面而非變數：

var ErrTest1 = errors.New("ErrTest1")

func IsErrTest1(err error) bool{
  return err == ErrTest1
}

錯誤類型

#錯誤類型來路由錯誤處理邏輯，和錯誤哨兵有異曲同工的作用，由類型系統來提供錯誤種類的唯一性，使用方法如下：

type TestError {
}
func(err *TestError) Error() string{
	return "Test Error"
}
if err, ok := err.(TestError); ok {
	//TODO 错误分支处理
}

err := something()
switch err := err.(type) {
case nil:
        // call succeeded, nothing to do
case *TestError:
        fmt.Println("error occurred on line:", err.Line)
default:
// unknown error
}

相比較於哨兵，錯誤類型的不變性更好，而且可以使用switch來提供優雅的路由策略。但這使得使用方依舊無法避免對於套件的過重依賴。

使用介面拋出更複雜，多樣的錯誤，依舊需要改變呼叫方的程式碼。

錯誤黑盒（依賴錯誤介面）

錯誤黑盒指的是不過度關心錯誤類型，將錯誤傳回給上層。當需要採取行動時，要針對錯誤的行為進行斷言，而非錯誤類型。

func fn() error{
	x, err := Foo()
	if err != nil {
		return err
	}
}

func main(){
	err := fn()
	if IsTemporary(err){
		fmt.Println("Temporary Error")
	}
}

type temporary interface {
        Temporary() bool
}
 
// IsTemporary returns true if err is temporary.
func IsTemporary(err error) bool {
        te, ok := err.(temporary)
        return ok && te.Temporary()
}

透過這樣的方式，1.直接就解耦了介面間的依賴，2. 錯誤處理路由和錯誤類型無關，而與具體行為有關，避免了膨脹的錯誤類型。

總結

錯誤哨兵和錯誤類型避免不了依賴過重的問題，只有錯誤黑盒能夠將問題從確定錯誤類型（變數）的處理邏輯變為確定錯誤行為。因此建議使用第三種方式來處理錯誤。

這裡必要要加一句，黑盒處理，返回錯誤並不意味著對錯誤的存在不理會或者是直接忽略，而是需要在合適的地方優雅得處理。在這個過程中，可以透過errors的Wrap，Zap打log等方式，在錯誤逐層傳回的過程中記錄呼叫連結的上下文訊息。

func authenticate() error{
	return fmt.Errorf("authenticate")
}

func AuthenticateRequest() error {
	err := authenticate()
	// OR logger.Info("authenticate fail %v", err)
	if err != nil {
		return errors.Wrap(err, "AuthenticateRequest")
	}
	return nil
}

func main(){
	err := AuthenticateRequest()
	fmt.Printf("%+v\n", err)
	fmt.Println("##########")
	fmt.Printf("%v\n", errors.Cause(err))
}

// 打印信息
authenticate
AuthenticateRequest
main.AuthenticateRequest
	/Users/hekangle/MyPersonProject/go-pattern/main.go:17
main.main
	/Users/hekangle/MyPersonProject/go-pattern/main.go:23
runtime.main
	/usr/local/Cellar/go@1.13/1.13.12/libexec/src/runtime/proc.go:203
runtime.goexit
	/usr/local/Cellar/go@1.13/1.13.12/libexec/src/runtime/asm_amd64.s:1357
##########
authenticate

【相關推薦：Go影片教學、程式設計教學】

以上是golang怎麼進行錯誤處理的詳細內容。更多資訊請關注PHP中文網其他相關文章！