一文教你如何优雅处理Golang中的异常
阿拉懒神灯 人气:0我们在使用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嵌套有多可怕,我们没必要一味追求代码的简洁,从而使用各种技巧去“优化”它,只要代码不冗余,清晰,简单就可以了。
加载全部内容