关于Go程序错误处理的一些建议
Go的错误处理这块是日常被大家吐槽较多的地方,我在工作中也观察到一些现象,比较严重的是在各层级的逻辑代码中对错误的处理有些重复。
比如,有人写代码就会在每一层都判断错误并记录日志,从代码层面看,貌似很严谨,但是如果看日志会发现一堆重复的信息,等到排查问题时反而会造成干扰。
今天给大家总结三点Go
代码错误处理相关的最佳实践给大家。
这些最佳实践也是网上一些前辈分享的,我自己实践后在这里用自己的语言描述出来,希望能对大家有所帮助。
认识error
Go
程序通过error
类型的值表示错误
error
类型是一个内建接口类型,该接口只规定了一个返回字符串值的Error
方法。
type error interface {Error() string
}
Go
语言的函数经常会返回一个error
值,调用者通过测试error
值是否是nil
来进行错误处理。
i, err := strconv.Atoi("42")
if err != nil {fmt.Printf("couldn't convert number: %v\n", err)return
}
fmt.Println("Converted integer:", i)
error
为nil
时表示成功;非nil
的error
表示失败。
自定义错误记得要实现error接口
我们经常会定义符合自己需要的错误类型,但是记住要让这些类型实现error
接口,这样就不用在调用方的程序里引入额外的类型。
比如下面我们自己定义了myError
这个类型,如果不实现error
接口的话,调用者的代码中就会被myError
这个类型侵入。比如下面的run
函数,在定义返回值类型时,直接定义成error
即可。
package myerrorimport ("fmt""time"
)type myError struct {Code intWhen time.TimeWhat string
}func (e *myError) Error() string {return fmt.Sprintf("at %v, %s, code %d",e.When, e.What, e.Code)
}func run() error {return &MyError{1002,time.Now(),"it didn't work",}
}func TryIt() {if err := run(); err != nil {fmt.Println(err)}
}
如果myError
不实现error
接口的话,这里的返回值类型就要定义成myError
类型。可想而知,紧接着调用者的程序里就要通过myError.Code == xxx
来判断到底是哪种具体的错误(当然想要这么干得先把myError
改成导出的MyError
)。
那调用者判断自定义error
是具体哪种错误的时候应该怎么办呢,myError
并未向包外暴露,答案是通过向包外暴露检查错误行为的方法来实现。
myerror.IsXXXError(err)
...
抑或是通过比较error
本身与包向外暴露的常量错误是否相等来判断,比如操作文件时常用来判断文件是否结束的io.EOF
。
类似的还有gorm.ErrRecordNotFound
等各种开源包对外暴露的错误常量。
if err != io.EOF {return err
}
错误处理常犯的错误
先看一段简单的程序,看大家能不能发现一些细微的问题
func WriteAll(w io.Writer, buf []byte) error {_, err := w.Write(buf)if err != nil {log.Println("unable to write:", err) // annotated error goes to log filereturn err // unannotated error returned to caller}return nil
}func WriteConfig(w io.Writer, conf *Config) error {buf, err := json.Marshal(conf)if err != nil {log.Printf("could not marshal config: %v", err)return err}if err := WriteAll(w, buf); err != nil {log.Println("could not write config: %v", err)return err}return nil
}func main() {err := WriteConfig(f, &conf)fmt.Println(err) // io.EOF
}
错误处理常犯的两个问题
上面程序的错误处理暴露了两个问题:
底层函数
WriteAll
在发生错误后,除了向上层返回错误外还向日志里记录了错误,上层调用者做了同样的事情,记录日志然后把错误再返回给程序顶层。因此在日志文件中得到一堆重复的内容
unable to write: io.EOF
could not write config: io.EOF
...
2. 在程序的顶部,虽然得到了原始错误,但没有相关内容,换句话说没有把WriteAll
、WriteConfig
记录到 log 里的那些信息包装到错误里,返回给上层。
针对这两个问题的解决方案可以是,在底层函数WriteAll
、WriteConfig
中为发生的错误添加上下文信息,然后将错误返回上层,由上层程序最后处理这些错误。
一种简单的包装错误的方法是使用fmt.Errorf
函数,给错误添加信息。
func WriteConfig(w io.Writer, conf *Config) error {buf, err := json.Marshal(conf)if err != nil {return fmt.Errorf("could not marshal config: %v", err)}if err := WriteAll(w, buf); err != nil {return fmt.Errorf("could not write config: %v", err)}return nil
}
func WriteAll(w io.Writer, buf []byte) error {_, err := w.Write(buf)if err != nil {return fmt.Errorf("write failed: %v", err)}return nil
}
给错误附加上下文信息
fmt.Errorf
只是给错误添加了简单的注解信息,如果你想在添加信息的同时还加上错误的调用栈,可以借助github.com/pkg/errors
这个包提供的错误包装能力。
//只附加新的信息
func WithMessage(err error, message string) error//只附加调用堆栈信息
func WithStack(err error) error//同时附加堆栈和信息
func Wrap(err error, message string) error
有包装方法,就有对应的解包方法,Cause
方法会返回包装错误对应的最原始错误--即会递归地进行解包。
func Cause(err error) error
下面是使用github.com/pkg/errors
改写后的错误处理程序
func ReadFile(path string) ([]byte, error) {f, err := os.Open(path)if err != nil {return nil, errors.Wrap(err, "open failed")}defer f.Close()buf, err := ioutil.ReadAll(f)if err != nil {return nil, errors.Wrap(err, "read failed")}return buf, nil
}
func ReadConfig() ([]byte, error) {home := os.Getenv("HOME")config, err := ReadFile(filepath.Join(home, ".settings.xml"))return config, errors.WithMessage(err, "could not read config")
}func main() {_, err := ReadConfig()if err != nil {fmt.Printf("original error: %T %v\n", errors.Cause(err), errors.Cause(err))fmt.Printf("stack trace:\n%+v\n", err)os.Exit(1)}
}
上面格式化字符串时用的 %+v 是在 % v 基础上,对值进行展开,即展开复合类型值,比如结构体的字段值等明细。
这样既能给错误添加调用栈信息,又能保留对原始错误的引用,通过Cause
可以还原到最初始引发错误的原因。
总结
总结一下,错误处理的原则就是:
错误只在逻辑的最外层处理一次,底层只返回错误。
底层除了返回错误外,要对原始错误进行包装,增加错误信息、调用栈等这些有利于排查的上下文信息。
给网管个星标,第一时间吸我的知识
关于Go程序错误处理的一些建议相关推荐
- explorer.exe应用程序错误说明 0X000000该内存不能为read的解决方法
0X000000该内存不能为read的解决方法 出现这个现象有方面的,一是硬件,即内存方面有问题,二是软件,这就有多方面的问题了. 一:先说说硬件: 一般来说,电脑硬件是很不容易坏的.内存出现问题的可 ...
- 提高WPF程序性能的几条建议
原文:提高WPF程序性能的几条建议 这篇博客将介绍一些提高WPF程序的建议(水平有限,如果建议有误,请指正.) 1. 加快WPF程序的启动速度: (1).减少需要显示的元素数量,去除不需要或者冗余的X ...
- 《编写高质量代码:改善c程序代码的125个建议》——建议2-6:防止无符号整数回绕...
本节书摘来自华章计算机<编写高质量代码:改善c程序代码的125个建议>一书中的第1章,建议2-6,作者:马 伟 更多章节内容可以访问云栖社区"华章计算机"公众号查看. ...
- 《编写高质量代码:改善c程序代码的125个建议》——第1章 数据,程序设计之根本建议1:认识ANSI C...
本节书摘来自华章计算机<编写高质量代码:改善c程序代码的125个建议>一书中的第1章,建议1,作者:马 伟 更多章节内容可以访问云栖社区"华章计算机"公众号查看. 第1 ...
- (转)explorer.exe应用程序错误:0x000000该内存不能为read的解决方法
0X000000该内存不能为read的解决方法 出现这个现象有多方面的原因,一是硬件,即内存方面有问题,二是软件,这就有多方面的问题了. 一.先说说硬件: 一般来说,电脑硬件是很不容易坏的.内存出现问 ...
- windows核心编程-第一章 对程序错误的处理
第一章-对程序错误的处理 在开始介绍Microsoft Windows 的特性之前,必须首先了解 Wi n d o w s的各个函数是如何进行错误处理的. 当调用一个Wi n d o w s函数时,它 ...
- 给Android程序员的六个建议
给Android程序员的六个建议 分类: 安卓相关2015-07-14 23:58 177人阅读 评论(0) 收藏 举报 android程序员 如果你一年前写的代码 , 在现在看来你还感觉写的很不错 ...
- 《编写高质量代码:改善c程序代码的125个建议》——建议4-1:整数转换为新类型时必须做范围检查...
本节书摘来自华章计算机<编写高质量代码:改善c程序代码的125个建议>一书中的第1章,建议4-1,作者:马 伟 更多章节内容可以访问云栖社区"华章计算机"公众号查看. ...
- microsoft vbscript编译器错误怎么解决_win7系统ie应用程序错误怎么办 ie应用程序错误解决方法【详解】...
windows系统自带的ie浏览器很少用户会去使用到,它运行起来比其他的浏览器要慢很多,而且经常会出现各种各样的问题,最近有位win7系统用户,在使用ie浏览器的时候,发生了应用程序错误的情况,那么w ...
最新文章
- php 函数导航,PHP经典分页导航函数
- JNI与底层调用-1
- linux中awd的详细使用方法,求教awdflash的使用方法,详细些,我是初學者。
- 模型训练速度过慢,GPU利用率低
- 为什么我不建议你买保险?
- 简明 XHTML 1.0 参考手册
- 7、mysql中的表结构操作
- [开源]STM32F103RBT6最小系统,LEDx2,KEYx4
- 人力资源管理(HR)专业书籍推荐
- 浪涌保护器ant120_ANT120/530/1P浪涌保护器服务周到漳州
- php 自定义模板标签,自定义模板解析list标签
- 牛顿柯特斯求积公式matlab,牛顿-柯特斯求积公式总结.ppt
- Python代码解析LRC歌词文件
- html5 dreamlive,DREAM LIVE 5th Tour Stargazer即将开演
- Elasticsearch 7.9 之 Frozen indices
- 火影忍者精剪版 纯战役没有回忆
- 疑似小米汽车全车设计效果图曝光 小米Logo上车
- 关于SQL SERVER注释快捷键
- ABB机器人学习笔记(七)-机器人编程
- 关于builder模式的使用