在几天前写的代码中,犯了几个比较典型的错误,带来不小的麻烦。特在此复现一下,吸取教训。
成都创新互联是创新、创意、研发型一体的综合型网站建设公司,自成立以来公司不断探索创新,始终坚持为客户提供满意周到的服务,在本地打下了良好的口碑,在过去的十年时间我们累计服务了上千家以及全国政企客户,如成都办公空间设计等企业单位,完善的项目管理流程,严格把控项目进度与质量监控加上过硬的技术实力获得客户的一致赞誉。
情景描述
代码中需要实现一个客户端与服务器的数据重传机制,通过write写数据给服务器,read读取服务器返回。一旦中途发生错误,每隔1s就尝试重新写读数据。当超过上下文时间,重传失败。重传实现代码retry如下。
- func retry(ctx context.Context) (data string, err error) {
- LOOP:
- for i:=1;;i++{
- err = write()
- if err == nil{
- res, err := read()
- if err == nil{
- data = string(res)
- return data, err
- }
- }
- log.Printf("change data failed, err: %v, retry times : %d\n", err, i)
- select {
- case <-ctx.Done():
- log.Printf("retry failed")
- break LOOP
- case <-time.After(1 * time.Second):
- }
- }
- return "", err
- }
读写服务器数据函数和调用重传代码mock如下。
- func write() error {
- return nil
- }
- func read() ([]byte, error) {
- return []byte("hello world"), errors.New("this is a error")
- }
- func main() {
- ctx,_ := context.WithTimeout(context.Background(),5*time.Second)
- _, _ = retry(ctx)
- time.Sleep(10*time.Second)
- }
write返回err为nil,read有非nil返回。这种情况下,日志输出如下。
- 2020/07/05 09:30:57 change data failed, err:
, retry times : 1 - 2020/07/05 09:30:58 change data failed, err:
, retry times : 2 - 2020/07/05 09:30:59 change data failed, err:
, retry times : 3 - 2020/07/05 09:31:00 change data failed, err:
, retry times : 4 - 2020/07/05 09:31:01 change data failed, err:
, retry times : 5 - 2020/07/05 09:31:02 retry failed
原因分析
可以看到的是,如预想的一样:当发生错误时,就重新尝试write和read。即重传机制生效。但是,日志中为何err会为nil,read方法的错误返回被吞掉了?
经过排查,发现原因就在于——Go语法糖:=(短变量声明)的不当使用。
- err = write()
- if err == nil{
- res, err := read()
- if err == nil{
- data = string(res)
- return data, err
- }
- }
- log.Printf("change data failed, err: %v, retry times : %d\n", err, i)
在retry中,err是已被声明的变量类型error。由于read返回的是两个变量,故小菜刀在此利用短变量声明res变量,接受read的第一个返回参数。但是,此举会改变err的作用范围:err成为了一个局部变量。什么意思呢?即此时的err被短变量声明所作用,成为了新声明对象,它只能作用于内部区域了。对于外部log.Printf而言,其引用到的err还是write方法生成的err对象。因此,即使read方法返回的err不为空,log.Printf打印的还是write方法的err结果,导致read的err内容被吞。
因此,为了避免此类错误发生,相应代码调整如下。
- var res []byte
- res, err = read()
- if err == nil{
- data = string(res)
- return data, err
- }
此时,当read返回err非nil时,日志打印如下。
- 2020/07/05 09:46:16 change data failed, err: this is a error, retry times : 1
- 2020/07/05 09:46:17 change data failed, err: this is a error, retry times : 2
- 2020/07/05 09:46:18 change data failed, err: this is a error, retry times : 3
- 2020/07/05 09:46:19 change data failed, err: this is a error, retry times : 4
- 2020/07/05 09:46:20 change data failed, err: this is a error, retry times : 5
- 2020/07/05 09:46:21 retry failed
总结
一、Go语法糖——短变量声明(:=)使用注意事项。
二、异常判断规则
在上述场景代码中,是一个多层级条件判断的情形,其判断规则是err为nil。但这是一种不恰当的处理逻辑。合理的判断条件,是对异常情况作判断,而将正常逻辑置于条件之外。那么,修改后的retry条件判断逻辑应该如下所示。
- func retry(ctx context.Context) (data string, err error) {
- LOOP:
- for i:=1;;i++{
- err = write()
- if err != nil{
- log.Printf("write data failed, err: %v, retry times : %d\n", err, i)
- select {
- case <-ctx.Done():
- log.Printf("retry failed")
- break LOOP
- case <-time.After(1 * time.Second):
- }
- continue
- }
- res, err := read()
- if err != nil{
- log.Printf("read data failed, err: %v, retry times : %d\n", err, i)
- select {
- case <-ctx.Done():
- log.Printf("retry failed")
- break LOOP
- case <-time.After(1 * time.Second):
- }
- continue
- }
- data = string(res)
- return data, err
- }
- return "", err
- }
这样,正常的处理流程,其主逻辑均在最外层,只有异常情况(err!=nil)才进入异常处理逻辑。当采用这种判断规则之后,就不存在多层条件嵌套语句,由语法糖带来的问题,也不复存在。
分享标题:Go语言一次真实的错误吞并的教训
转载来源:http://www.shufengxianlan.com/qtweb/news12/43312.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联