這是一個建立於 的文章,其中的資訊可能已經有所發展或是發生改變。
隨著使用golang越來越頻繁,發現golang有一個地方非常不方便,就是在錯誤處理方面。先來看看golang中通常的錯誤處理方法:
通常的error處理
| 123456789101112131415161718 |
packagemain import ( "errors" "fmt") func a() (err error) { err = errors.New("錯誤") return} func main() { err := a() iferr != nil { fmt.Println(err) }} |
函數在返回的時候增加error類型的傳回值,如果有錯誤則賦值給err,在調用函數處對err進行判斷,如果不為nil則處理錯誤。這種方式在嵌套的層少的時候還好辦,要是嵌套的層多了那就要一級一級的返回err,顯然會很麻煩。如下面的代碼:
| 123456789101112131415161718192021222324252627282930313233343536 |
packagemain import ( "errors" "fmt") func a() (err error) { err = b() iferr != nil { return } err = c() iferr != 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() iferr != nil { fmt.Println(err) }} |
a函數內調用了b和c函數,調用後都要進行err != nil的判斷,如果再來個d方法,e方法,那豈不是非常麻煩。在實際開發的時候,這種多層嵌套也經常存在,比如使用者註冊功能就要判斷很多東西:表單驗證是否OK;使用者是否已經存在;資料插入是否OK等等。
用panic的嘗試
於是我就想有沒什麼辦法更加方便,至少不用調用每個函數都判斷下err!=nil,這樣就可以省掉三行代碼。瞭解到golang中的panic方法可以直接中斷流程,感覺到沿著這個應該能找到解決方案。瞭解了下panic的詳細使用,其實也很簡單,就是panic一下,如果需要捕獲這個panic的錯誤,就在外圍的方法事先聲明recover方法。看下代碼:
| 12345678910111213141516171819 |
packagemain import ( "log") func main() { deferfunc() { ifr := recover(); r != nil { log.Printf("Runtime error caught: %v", r) } }() a()} func a() { panic("a內錯誤")} |
a函數內拋出了錯誤,被外圍事先defer的函數recover到,接著就能對錯誤進行處理了。用這樣的方式來改造上面用err處理的代碼看看。
| 12345678910111213141516171819202122232425262728293031 |
packagemain import ( "log") func a() { b() c() panic("a內錯誤") return} func b() { panic("b內錯誤")} func c() (err error) { panic("c內錯誤")} func main() { deferfunc() { ifr := recover(); r != nil { log.Printf("Runtime error caught: %v", r) } }() a()} |
可以看到整個代碼都簡潔了很多,當然這裡的代碼比較簡單可能看不出什麼太大效果,在業務較為繁雜、經常要做各種校正的時候就可以顯現出簡潔了。
在開發api介面項目的時候,我會封裝好recover的方法用來處理內部返回的錯誤資訊,然後統一輸出到用戶端,感覺便捷很多。
轉載請註明:快樂編程 » golang用panic和recover做商務程序中斷的嘗試