关于Go程序错误处理的一些建议

开发 后端
Go的错误处理这块是日常被大家吐槽较多的地方,我在工作中也观察到一些现象,比较严重的是在各层级的逻辑代码中对错误的处理有些重复。

[[425992]]

本文转载自微信公众号「网管叨bi叨」,作者网管 。转载本文请联系网管叨bi叨公众号。

Go的错误处理这块是日常被大家吐槽较多的地方,我在工作中也观察到一些现象,比较严重的是在各层级的逻辑代码中对错误的处理有些重复。

比如,有人写代码就会在每一层都判断错误并记录日志,从代码层面看,貌似很严谨,但是如果看日志会发现一堆重复的信息,等到排查问题时反而会造成干扰。

今天给大家总结三点Go代码错误处理相关的最佳实践给大家。

这些最佳实践也是网上一些前辈分享的,我自己实践后在这里用自己的语言描述出来,希望能对大家有所帮助。

认识error

Go程序通过error类型的值表示错误

error类型是一个内建接口类型,该接口只规定了一个返回字符串值的Error方法。

  1. type error interface { 
  2.     Error() string 

Go语言的函数经常会返回一个error值,调用者通过测试error值是否是nil来进行错误处理。

  1. i, err := strconv.Atoi("42"
  2. if err != nil { 
  3.     fmt.Printf("couldn't convert number: %v\n", err) 
  4.     return 
  5. fmt.Println("Converted integer:", i) 

error为nil时表示成功;非nil的error表示失败。

自定义错误记得要实现error接口

我们经常会定义符合自己需要的错误类型,但是记住要让这些类型实现error接口,这样就不用在调用方的程序里引入额外的类型。

比如下面我们自己定义了myError这个类型,如果不实现error接口的话,调用者的代码中就会被myError这个类型侵入。比如下面的run函数,在定义返回值类型时,直接定义成error即可。

  1. package myerror 
  2.  
  3. import ( 
  4.  "fmt" 
  5.  "time" 
  6.  
  7. type myError struct { 
  8.  Code int 
  9.  When time.Time 
  10.  What string 
  11.  
  12. func (e *myError) Error() string { 
  13.  return fmt.Sprintf("at %v, %s, code %d"
  14.   e.When, e.What, e.Code) 
  15.  
  16. func run() error { 
  17.  return &MyError{ 
  18.     1002, 
  19.     time.Now(), 
  20.     "it didn't work"
  21.  } 
  22.  
  23. func TryIt() { 
  24.  if err := run(); err != nil { 
  25.   fmt.Println(err) 
  26.  } 

如果myError不实现error接口的话,这里的返回值类型就要定义成myError类型。可想而知,紧接着调用者的程序里就要通过myError.Code == xxx 来判断到底是哪种具体的错误(当然想要这么干得先把myError改成导出的MyError)。

那调用者判断自定义error是具体哪种错误的时候应该怎么办呢,myError并未向包外暴露,答案是通过向包外暴露检查错误行为的方法来实现。

  1. myerror.IsXXXError(err)  
  2. ... 

抑或是通过比较error本身与包向外暴露的常量错误是否相等来判断,比如操作文件时常用来判断文件是否结束的io.EOF。

类似的还有gorm.ErrRecordNotFound等各种开源包对外暴露的错误常量。

  1. if err != io.EOF { 
  2.     return err 

错误处理常犯的错误

先看一段简单的程序,看大家能不能发现一些细微的问题

  1. func WriteAll(w io.Writer, buf []byte) error { 
  2.     _, err := w.Write(buf) 
  3.     if err != nil { 
  4.         log.Println("unable to write:", err) // annotated error goes to log file 
  5.         return err                           // unannotated error returned to caller 
  6.     } 
  7.     return nil 
  8.  
  9. func WriteConfig(w io.Writer, conf *Config) error { 
  10.     buf, err := json.Marshal(conf) 
  11.     if err != nil { 
  12.         log.Printf("could not marshal config: %v", err) 
  13.         return err 
  14.     } 
  15.     if err := WriteAll(w, buf); err != nil { 
  16.         log.Println("could not write config: %v", err) 
  17.         return err 
  18.     } 
  19.     return nil 
  20.  
  21. func main() { 
  22.     err := WriteConfig(f, &conf) 
  23.     fmt.Println(err) // io.EOF 

错误处理常犯的两个问题

上面程序的错误处理暴露了两个问题:

底层函数WriteAll在发生错误后,除了向上层返回错误外还向日志里记录了错误,上层调用者做了同样的事情,记录日志然后把错误再返回给程序顶层。

因此在日志文件中得到一堆重复的内容

  1. unable to write: io.EOF 
  2. could not write config: io.EOF 
  3. ... 

2. 在程序的顶部,虽然得到了原始错误,但没有相关内容,换句话说没有把WriteAll、WriteConfig记录到 log 里的那些信息包装到错误里,返回给上层。

针对这两个问题的解决方案可以是,在底层函数WriteAll、WriteConfig中为发生的错误添加上下文信息,然后将错误返回上层,由上层程序最后处理这些错误。

一种简单的包装错误的方法是使用fmt.Errorf函数,给错误添加信息。

  1. func WriteConfig(w io.Writer, conf *Config) error { 
  2.     buf, err := json.Marshal(conf) 
  3.     if err != nil { 
  4.         return fmt.Errorf("could not marshal config: %v", err) 
  5.     } 
  6.     if err := WriteAll(w, buf); err != nil { 
  7.         return fmt.Errorf("could not write config: %v", err) 
  8.     } 
  9.     return nil 
  10. func WriteAll(w io.Writer, buf []byte) error { 
  11.     _, err := w.Write(buf) 
  12.     if err != nil { 
  13.         return fmt.Errorf("write failed: %v", err) 
  14.     } 
  15.     return nil 

给错误附加上下文信息

fmt.Errorf只是给错误添加了简单的注解信息,如果你想在添加信息的同时还加上错误的调用栈,可以借助github.com/pkg/errors这个包提供的错误包装能力。

  1. //只附加新的信息 
  2. func WithMessage(err error, message string) error 
  3.  
  4. //只附加调用堆栈信息 
  5. func WithStack(err error) error 
  6.  
  7. //同时附加堆栈和信息 
  8. func Wrap(err error, message string) error 

有包装方法,就有对应的解包方法,Cause方法会返回包装错误对应的最原始错误--即会递归地进行解包。

  1. func Cause(err error) error 

下面是使用github.com/pkg/errors改写后的错误处理程序

  1. func ReadFile(path string) ([]byte, error) { 
  2.     f, err := os.Open(path) 
  3.     if err != nil { 
  4.         return nil, errors.Wrap(err, "open failed"
  5.     } 
  6.     defer f.Close() 
  7.     buf, err := ioutil.ReadAll(f) 
  8.     if err != nil { 
  9.         return nil, errors.Wrap(err, "read failed"
  10.     } 
  11.     return buf, nil 
  12. func ReadConfig() ([]byte, error) { 
  13.     home := os.Getenv("HOME"
  14.     config, err := ReadFile(filepath.Join(home, ".settings.xml")) 
  15.     return config, errors.WithMessage(err, "could not read config"
  16.  
  17.  
  18. func main() { 
  19.     _, err := ReadConfig() 
  20.     if err != nil { 
  21.         fmt.Printf("original error: %T %v\n", errors.Cause(err), errors.Cause(err)) 
  22.         fmt.Printf("stack trace:\n%+v\n", err) 
  23.         os.Exit(1) 
  24.     } 

上面格式化字符串时用的 %+v 是在 % v 基础上,对值进行展开,即展开复合类型值,比如结构体的字段值等明细。

这样既能给错误添加调用栈信息,又能保留对原始错误的引用,通过Cause可以还原到最初始引发错误的原因。

总结

总结一下,错误处理的原则就是:

错误只在逻辑的最外层处理一次,底层只返回错误。

 

底层除了返回错误外,要对原始错误进行包装,增加错误信息、调用栈等这些有利于排查的上下文信息。

 

责任编辑:武晓燕 来源: 网管叨bi叨
相关推荐

2021-09-27 15:33:48

Go 开发技术

2020-08-20 10:16:56

Golang错误处理数据

2021-04-29 09:02:44

语言Go 处理

2014-11-17 10:05:12

Go语言

2015-08-26 09:31:26

程序员建议

2015-08-26 08:31:35

核心程序员成长

2011-04-27 09:21:09

程序员

2022-09-05 08:55:15

Go2提案语法

2021-09-13 07:53:31

Go错误处理

2022-12-12 08:53:53

Go版本方式

2019-10-30 14:58:45

MVCAndroid表现层

2023-10-26 15:49:53

Go日志

2021-09-27 23:28:29

Go多协程并发

2020-12-17 06:25:05

Gopanic 模式

2009-11-26 15:10:08

VS2005资源

2023-03-10 08:48:29

2011-07-13 09:13:56

Android设计

2020-09-15 08:28:17

JavaScript错误处理

2021-04-14 07:08:14

Nodejs错误处理

2011-07-27 10:52:02

Oracleredolog
点赞
收藏

51CTO技术栈公众号