golang如何進行錯誤處理

這篇“golang如何進行錯誤處理”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“golang如何進行錯誤處理”文章吧。

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

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

以上就是關于“golang如何進行錯誤處理”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。