建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號「腦子進煎魚了」，作者陳煎魚 。轉(zhuǎn)載本文請聯(lián)系腦子進煎魚了公眾號。
創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都網(wǎng)站設(shè)計、成都做網(wǎng)站、可克達拉網(wǎng)絡(luò)推廣、小程序定制開發(fā)、可克達拉網(wǎng)絡(luò)營銷、可克達拉企業(yè)策劃、可克達拉品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供可克達拉建站搭建服務(wù)，24小時服務(wù)熱線：18980820575，官方網(wǎng)址：www.cdcxhl.com
大家好，我是煎魚。
前段時間我分享了文章 《先睹為快，Go2 Error 的掙扎之路》后，和一位朋友進行了一次深度交流，他給我分享了他們項目組對于 Go 錯誤處理的方式調(diào)整。
簡單來講，就是在業(yè)務(wù)代碼中使用 panic 的方式來替代 “永無止境” 的 if err != nil。
我們一起來看看是怎么做，又有什么優(yōu)缺點，互相學(xué)習(xí)一輪。
為什么想替換
在 Go 語言中 if err != nil 寫的太多，還要管方法聲明各種，嫌麻煩又不方便：
- err := foo()
- if err != nil {
- //do something..
- return err
- }
- err := foo()
- if err != nil {
- //do something..
- return err
- }
- err := foo()
- if err != nil {
- //do something..
- return err
- }
- err := foo()
- if err != nil {
- //do something..
- return err
- }
上述還是示例代碼，比較直面。若是在工程實踐，還得各種 package 跳來跳去加 if err != nil，講更繁瑣，要去關(guān)心整體的上下游。
其余更具體的就不贅述了，可以關(guān)注我的公眾號翻看先前的文章。
怎么替換 err != nil
不想寫 if err != nil 的代碼，方式之一就是用 panic 來替代他。
示例代碼如下：
- func GetFish(db *sql.DB, name string) []string {
- rows, err := db.Query("select name from users where `name` = ?", name)
- if err != nil {
- panic(err)
- }
- defer rows.Close()
- var names []string
- for rows.Next() {
- var name string
- err := rows.Scan(&name)
- if err != nil {
- panic(err)
- }
- names = append(names, name)
- }
- err = rows.Err()
- if err != nil {
- panic(err)
- }
- return names
- }
在上述業(yè)務(wù)代碼中，我們通過 panic 的方式取代了 return err 的函數(shù)返回，自然其所關(guān)聯(lián)的下游業(yè)務(wù)代碼也就不需要編寫 if err != nil 的代碼：
- func main() {
- fish1 := GetFish(db, "煎魚")
- fish2 := GetFish(db, "咸魚")
- fish3 := GetFish(db, "摸魚")
- ...
- }
同時在轉(zhuǎn)換為使用 panic 模式的錯誤機制后，我們必須要在外層增加 recover 方法：
- func AppRecovery() gin.HandlerFunc {
- return func(c *gin.Context) {
- defer func() {
- if err := recover(); err != nil {
- if _, ok := err.(AppErr); ok {
- // do something...
- } else {
- panic(err)
- }
- }
- }()
- }
- }
每次 panic 后根據(jù)其拋出的錯誤進行斷言，識別是否定制的 AppErr 錯誤類型，若是則可以進行一系列的處理動作。
否則可繼續(xù)向上 panic 拋出給頂級的 Recovery 方法進行處理。
這就是一個相對完整的 panic 錯誤鏈路處理了。
優(yōu)缺點
- 從優(yōu)點上來講：
- 整體代碼結(jié)構(gòu)看起來更加的簡潔，僅專注于實現(xiàn)邏輯即可。
- 不需要關(guān)注和編寫冗雜的 if err != nil 的錯誤處理代碼。
- 從缺點上來講：
- 認知負擔(dān)的增加，需要參加項目的每一個新老同學(xué)都清楚該模式，要做一個基本規(guī)范或培訓(xùn)。
- 存在一定的性能開銷，每次 panic 都存在用戶態(tài)的上下文切換。
- 存在一定的風(fēng)險性，一旦 panic 沒有 recover 住，就會導(dǎo)致事故。
- Go 官方并不推薦，與 panic 本身的定義相違背，也就是 panic 與 error 的概念混淆。
總結(jié)
在今天這篇文章給大家分享了如何使用 panic 的方式來處理 Go 的錯誤，其必然有利必有有弊，需要做一個權(quán)衡了。
新聞標題：Go錯誤處理：用panic取代err!=nil的模式
瀏覽地址：http://m.5511xx.com/article/djgdsgi.html
