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)和記錄錯誤呼叫堆疊。
哨兵指的是用特定值的變數作為錯誤處理分支的判定條件，常見的應用場景有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怎麼進行錯誤處理的詳細內容。更多資訊請關注PHP中文網其他相關文章！
