golang用panic和recover作業務流程中斷的嘗試

隨着使用golang愈來愈頻繁，發現golang有一個地方很是不方便，就是在錯誤處理方面。先來看看golang中一般的錯誤處理方法：

一般的error處理

package main
 
import (
    "errors"
    "fmt"
)
 
func a() (err error) {
    err = errors.New("錯誤")
    return
}
 
func main() {
    err := a()
    if err != nil {
        fmt.Println(err)
    }
}

函數在返回的時候增長error類型的返回值，若是有錯誤則賦值給err，在調用函數處對err進行判斷，若是不爲nil則處理錯誤。這種方式在嵌套的層少的時候還好辦，要是嵌套的層多了那就要一級一級的返回err，顯然會很麻煩。以下面的代碼： 

package main
 
import (
    "errors"
    "fmt"
)
 
func a() (err error) {
    err = b()
    if err != nil {
        return
    }
    err = c()
    if err != nil {
        return
    }
    err = errors.New("a內錯誤")
    return
}
 
func b() (err error) {
    err = errors.New("b內錯誤")
    return
}
 
func c() (err error) {
    err = errors.New("c內錯誤")
    return
}
 
func main() {
    err := a()
    if err != nil {
        fmt.Println(err)
    }
}

a函數內調用了b和c函數，調用後都要進行err != nil的判斷，若是再來個d方法，e方法，那豈不是很是麻煩。在實際開發的時候，這種多層嵌套也常常存在，好比用戶註冊功能就要判斷不少東西：表單驗證是否OK；用戶是否已經存在；數據插入是否OK等等。

用panic的嘗試

因而我就想有沒什麼辦法更加方便，至少不用調用每一個函數都判斷下err!=nil，這樣就能夠省掉三行代碼。瞭解到golang中的panic方法能夠直接中斷流程，感受到沿着這個應該能找到解決方法。瞭解了下panic的詳細使用，其實也很簡單，就是panic一下，若是須要捕獲這個panic的錯誤，就在外圍的方法事先聲明recover方法。看下代碼：

 

package main
 
import (
    "log"
)
 
func main() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("Runtime error caught: %v", r)
        }
    }()
 
    a()
}
 
func a() {
    panic("a內錯誤")
}

a函數內拋出了錯誤，被外圍事先defer的函數recover到，接着就能對錯誤進行處理了。用這樣的方式來改造上面用err處理的代碼看看。 

package main
 
import (
    "log"
)
 
func a() {
    b()
    c()
 
    panic("a內錯誤")
    return
}
 
func b() {
    panic("b內錯誤")
}
 
func c() (err error) {
    panic("c內錯誤")
}
 
func main() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("Runtime error caught: %v", r)
        }
    }()
 
    a()
}

能夠看到整個代碼都簡潔了不少，固然這裏的代碼比較簡單可能看不出什麼太大效果，在業務較爲繁雜、常常要作各類校驗的時候就能夠顯現出簡潔了。

在開發api接口項目的時候，我會封裝好recover的方法用來處理內部返回的錯誤信息，而後統一輸出到客戶端，感受便捷不少。