我們在使用Golang時,不可避免會遇到異常情況的處理,與Java、Python等語言不同的是,Go中並沒有try...catch...這樣的語句塊,我們知道在Java中使用try...catch...這種模式不僅能分離的錯誤與返回值和引數,也提供了結構化處理異常的可能,通過物件導向的思想,我們可以自定義錯誤類、子類,它們又可以包裝其他錯誤,確保錯誤上下文不會丟失。但是在Go中,異常是作為函數返回值,返回給呼叫方的,這個時候我們如何才能更好的處理異常呢?
對於異常的處理,我們應該把握三個原則:
不重複處理異常;
異常資訊中需要包含完整呼叫棧;
要提供異常的上下文資訊;
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函數中違背了【不重複處理異常】的原則,雖然這裡僅僅是列印,但是隻要你向上拋異常,呼叫方很有可能再次列印,這就導致紀錄檔中存在大量重複資訊,不便於分析。因為我們修改read函數:
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機制,所以會導致程式碼中使用大量if對錯誤進行處理,非常不優雅。
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 }
對於這類程式碼我們可以使用匿名函數進行簡化,我們將checkAttr和err的判斷封裝在匿名函數check中,一旦某一次check出現error,則都不會在進行後續的屬性校驗。
check := func(attr interface{}){ if err != nil{ return } err = checkAttr(attr) } check(employ.Name) check(employ.Age) check(employ.Salary) return err
當然,這種方式是還需要建立一個匿名函數以及一個error變數,這會讓我們的commitEmployInfoFromFile函數顯得不太乾淨,我們可以進一步優化:
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 }
當然,這種方式是有一定侷限性的,它只能在對於同一個業務物件的不斷操作下可以簡化錯誤處理,對於多個業務物件的話,還是得需要各種 if err != nil
的方式。
其實,對於Go的例外處理,我們不能說Golang不支援try catch,那它就不行,君不見try catch巢狀有多可怕,我們沒必要一味追求程式碼的簡潔,從而使用各種奇技淫巧去「優化」它,只要程式碼不冗餘,清晰,簡單就可以了。