一文教你如何優(yōu)雅處理Golang中的異常
我們在使用Golang時,不可避免會遇到異常情況的處理,與Java、Python等語言不同的是,Go中并沒有try...catch...這樣的語句塊,我們知道在Java中使用try...catch...這種模式不僅能分離的錯誤與返回值和參數(shù),也提供了結(jié)構(gòu)化處理異常的可能,通過面向?qū)ο蟮乃枷耄覀兛梢宰远x錯誤類、子類,它們又可以包裝其他錯誤,確保錯誤上下文不會丟失。但是在Go中,異常是作為函數(shù)返回值,返回給調(diào)用方的,這個時候我們?nèi)绾尾拍芨玫奶幚懋惓D兀?/p>
對于異常的處理,我們應(yīng)該把握三個原則:
- 不重復(fù)處理異常;
- 異常信息中需要包含完整調(diào)用棧;
- 要提供異常的上下文信息;
func read(filePath string) (string, error) { content ,err := ioutil.ReadFile(filePath) if err != nil { log.Printf("Read file err: %v", err) return "", err } return string(content), nil } func parse(content string) (Employ, error) { // 解析文件得到Employ對象 } func checkAttr(attr interface{}) error { // 校驗對象屬性 } func commitEmployInfoFromFile(filePath string) error { content, err := read(filePath) if err != nil { return errors.New("Read object file error") } employ, err := parse(content) if err != nil { return errors.New("Parse object content error") } if err = checkAttr(employ.Name); err != nil { return err } if err = checkAttr(employ.Age); err != nil { return err } if err = checkAttr(employ.Salary); err != nil { return err } return nil }
我們分析上面的代碼,可以很明顯看到read函數(shù)中違背了【不重復(fù)處理異常】的原則,雖然這里僅僅是打印,但是只要你向上拋異常,調(diào)用方很有可能再次打印,這就導(dǎo)致日志中存在大量重復(fù)信息,不便于分析。因為我們修改read函數(shù):
func read(filePath string) (string, error) { content ,err := ioutil.ReadFile(filePath) if err != nil { return "", err } return string(content), nil }
再來看看這一部分代碼,日志中僅僅打印了錯誤信息,但是缺少錯誤堆棧,這樣非常不利于問題代碼的定位。
content, err := read(filePath) if err != nil { return errors.New("Read object file error") } employ, err := parse(content) if err != nil { return errors.New("Parse object content error") }
上面的代碼還有一個問題,那就是錯誤信息都是簡單的字符串信息,缺少上下文信息,比如:
errors.New("Read object file error")
我們只能知道是文件讀取出錯了,但無法得知是哪個文件有問題,因此我們最好加入文件信息到日志中。改良后的代碼如下:
content, err := read(filePath) if err != nil { return fmt.Errorf("Read object file %v error: %v", filePath, err) } employ, err := parse(content) if err != nil { return fmt.Errorf("Parse object content error: %v", err) }
最后,我們再看看這一段代碼,這種寫法非常常見,很多剛使用Golang的朋友都覺得非常頭痛,由于Golang中沒有throw或raise機制,所以會導(dǎo)致代碼中使用大量if對錯誤進(jìn)行處理,非常不優(yōu)雅。
if err = checkAttr(employ.Name); err != nil { return err } if err = checkAttr(employ.Age); err != nil { return err } if err = checkAttr(employ.Salary); err != nil { return err }
對于這類代碼我們可以使用匿名函數(shù)進(jìn)行簡化,我們將checkAttr和err的判斷封裝在匿名函數(shù)check中,一旦某一次check出現(xiàn)error,則都不會在進(jìn)行后續(xù)的屬性校驗。
check := func(attr interface{}){ if err != nil{ return } err = checkAttr(attr) } check(employ.Name) check(employ.Age) check(employ.Salary) return err
當(dāng)然,這種方式是還需要創(chuàng)建一個匿名函數(shù)以及一個error變量,這會讓我們的commitEmployInfoFromFile函數(shù)顯得不太干凈,我們可以進(jìn)一步優(yōu)化:
type EmployChecker struct { err error } func (c *EmployChecker) check(attr interface{}) { if c.err == nil { c.err = checkAttr(attr) } } func commitEmployInfoFromFile(filePath string) error { content, err := read(filePath) if err != nil { return fmt.Errorf("Read object file %v error: %v", filePath, err) } employ, err := parse(content) if err != nil { return fmt.Errorf("Parse object content error: %v", err) } checker := EmployChecker{} checker.check(employ.Name) checker.check(employ.Age) checker.check(employ.Salary) err = checker.err return err }
當(dāng)然,這種方式是有一定局限性的,它只能在對于同一個業(yè)務(wù)對象的不斷操作下可以簡化錯誤處理,對于多個業(yè)務(wù)對象的話,還是得需要各種 if err != nil
的方式。
其實,對于Go的異常處理,我們不能說Golang不支持try catch,那它就不行,君不見try catch嵌套有多可怕,我們沒必要一味追求代碼的簡潔,從而使用各種技巧去“優(yōu)化”它,只要代碼不冗余,清晰,簡單就可以了。
到此這篇關(guān)于一文教你如何優(yōu)雅處理Golang中的異常的文章就介紹到這了,更多相關(guān)Golang處理異常內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Go?gRPC進(jìn)階教程gRPC轉(zhuǎn)換HTTP
這篇文章主要為大家介紹了Go?gRPC進(jìn)階教程gRPC轉(zhuǎn)換HTTP教程示例,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-06-06Go?模塊在下游服務(wù)抖動恢復(fù)后CPU占用無法恢復(fù)原因
這篇文章主要為大家介紹了Go?模塊在下游服務(wù)抖動恢復(fù)后CPU占用無法恢復(fù)原因詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-11-11Golang的os標(biāo)準(zhǔn)庫中常用函數(shù)的整理介紹
這篇文章主要介紹了Go語言的os標(biāo)準(zhǔn)庫中常用函數(shù),主要用來實現(xiàn)與操作系統(tǒng)的交互功能,需要的朋友可以參考下2015-10-10GOPROXY:解決go get golang.org/x包失敗問題
這篇文章主要介紹了GOPROXY:解決go get golang.org/x包失敗問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-01-01