Golang中巧用defer进行错误处理

问题引入

毫无疑问,错误处理是程序的重要组成部分,有效且优雅的处理错误是大多数程序员的追求。很多程序员都有C/C++的编程背景,Golang的程序员也不例外,他们处理错误有意无意的带着C/C++的烙印。

我们看看下面的例子,就有一种似曾相识的赶脚,代码如下:

func deferDemo() error {
    err := createResource1()
    if err != nil {
        return ERR_CREATE_RESOURCE1_FAILED
    }
    err = createResource2()
    if err != nil {
        destroyResource1()
        return ERR_CREATE_RESOURCE2_FAILED
    }

    err = createResource3()
    if err != nil {
        destroyResource1()
        destroyResource2()
        return ERR_CREATE_RESOURCE3_FAILED
    }

    err = createResource4()
    if err != nil {
        destroyResource1()
        destroyResource2()
        destroyResource3()
        return ERR_CREATE_RESOURCE4_FAILED
    }
    return nil
}

从代码的实现中可以看出:在一个函数中,当创建新资源失败时,则要清理所有前面已经创建成功的资源,这使得函数中有了重复代码的坏味道,比如destroyResource1函数调用了3次,destroyResource2函数调用了2次。

重构一:一个defer + 多个flag

Golang提供了一个很好用的关键字defer,当包含defer的函数执行完毕时(不管是通过return的正常结束,还是由于panic导致的异常结束),defer语句才被调用。

考虑到这一点,我们尝试将所有资源在defer语句中统一清理。由于函数返回时,不知道是否需要清理以及清理那些资源,所以要增加多个flag。

重构后的代码如下所示:

func deferDemo() error {
    flag := false
    flag1 := false
    flag2 := false
    flag3 := false

    defer func() {
        if !flag {
            if flag3 {
                 destroyResource3()
            }
            if flag2 {
                 destroyResource2()
            }
            if flag1 {
             destroyResource1()
            }
        }
    }()

    err := createResource1()
    if err != nil {
        return ERR_CREATE_RESOURCE1_FAILED
    }
    flag1 = true

    err = createResource2()
    if err != nil {
        return ERR_CREATE_RESOURCE2_FAILED
    }
    flag2 = true

    err = createResource3()
    if err != nil {
        return ERR_CREATE_RESOURCE3_FAILED
    }
    flag3 = true

    err = createResource4()
    if err != nil {
        return ERR_CREATE_RESOURCE4_FAILED
    }
    flag = true
    return nil
}

从重构后的代码可以看出,虽然消除了重复,但是引入了太多的flag:

  1. flag表示函数是否执行成功,即flag为true时表示函数执行成功,否则表示函数执行失败;在defer语句中,只有flag为false时才需要统一清理资源
  2. flagi表示第i个资源是否创建成功,即flagi为true时表示第i个资源创建成功,否则表示第i个资源创建失败;在defer语句中,只有flagi为true时才需要清理第i个资源

显然,这不是我们想要的

重构二:多个defer

看过linux源码的同学都知道,在内核代码中,很多地方都通过goto语句来集中处理错误,非常优雅。

我们用这种方法将重构前的代码用C语言写一下,代码如下所示:

ErrCode deferDemo()
{
    ErrCode err = createResource1();
    if (err != ERR_SUCC)
    {
        goto err_1;
    }

    err = createResource2();
    if (err != ERR_SUCC)
    {
        goto err_2;
    }

    err = createResource3();
    if (err != ERR_SUCC)
    {
        goto err_3;
    }

    err = createResource4();
    if (err != ERR_SUCC)
    {
        goto err_4;
    }

    return ERR_SUCC;

    err_4:
        destroyResource3();
    err_3:
        destroyResource2();
    err_2:
        destroyResource1();
    err_1:
        return ERR_FAIL;
}

没有重复,没有flag,错误处理也很优雅,感觉很爽,那以前在C/C++编码规范中禁止使用goto语句的规则确实有点过,呵呵...

从重构后的C代码中可以看出,create操作和destroy操作的顺序类似入栈和出栈的顺序:

  1. 伴随着create操作,destroy操作逐个入栈,顺序为1,2,3
  2. 出栈时是destroy操作,顺序为3,2,1

于是我们又想到了defer语句:当Golang的代码执行时,如果遇到defer语句,则压入堆栈,当函数返回时,会按照后进先出的顺序调用defer语句。

我们看一个例子,代码如下所示:

func main() {
    defer fmt.Println(1)
    defer fmt.Println(2)
    defer fmt.Println(3)
}

运行后,日志如下所示:

3
2
1

然而,有堆栈特性还不够,因为伴随着create操作,destroy操作入栈是有条件的:

  1. 如果create操作失败,则直接返回,那么defer语句没有执行,导致destroy操作没有入栈
  2. 如果create操作成功,则defer语句得到执行,destroy操作完成入栈

可见,destroy操作的入栈条件是create操作成功,但是destroy操作并不是一定执行,只有当某个create操作失败("err != nil")时,前面入栈的destory操作才需要执行,所以err的值也需要入栈。然而,destroy操作入栈时"err == nil" ,于是问题就变成:当err的值在后面变成非nil时,应该同步修改堆栈中的err值,即堆栈中传递的是引用或指针而不是值。

当err的引用或指针和destroy操作都需要入栈时,defer后面必须是一个闭包调用。我们知道,对于闭包的参数是值传递,而对于外部变量却是引用传递。为了简单优雅起见,我们将err不通过参数的指针传递,而通过外部变量的引用传递。

我们根据这个结论重构一下代码,如下所示:

func deferDemo() error {
    err := createResource1()
    if err != nil {
        return ERR_CREATE_RESOURCE1_FAILED
    }
    defer func() {
        if err != nil {
            destroyResource1()
        }
    }()

    err = createResource2()
    if err != nil {
        return ERR_CREATE_RESOURCE2_FAILED
    }
    defer func() {
        if err != nil {
            destroyResource2()
        }
    }()

    err = createResource3()
    if err != nil {
        return ERR_CREATE_RESOURCE3_FAILED
    }
    defer func() {
        if err != nil {
            destroyResource3()
        }
    }()

    err = createResource4()
    if err != nil {
        return ERR_CREATE_RESOURCE4_FAILED
    }
    return nil
}

本次重构消除了代码的坏味道,不由的感叹一句:”升级了,我的哥!“

小结

本文通过巧用defer,有效且优雅的处理了错误,该技巧应该被所有的Golang程序员掌握并大量使用。

原文发布于微信公众号 - Golang语言社区(Golangweb)

原文发表时间:2017-11-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Hongten

Lucene学习总结之三:Lucene的索引文件格式(1)

Lucene的索引里面存了些什么,如何存放的,也即Lucene的索引文件格式,是读懂Lucene源代码的一把钥匙。

12520
来自专栏Android 研究

OKHttp源码解析(五)--OKIO简介及FileSystem

okio是由square公司开发的,它补充了java.io和java.nio的不足,以便能够更加方便,快速的访问、存储和处理你的数据。OKHttp底层也是用该库...

28430
来自专栏分布式系统进阶

Librdkafka的基础数据结构 2 --- 定时器 原子操作与引用计数

引用了一个新的struct来将引用计数和调用信息结合起来, 使用链表来管理这个struct的对象. 每次对引用计数的操作都要操作这个链表.

11110
来自专栏源码之家

word如何自动分割成多个文档

47450
来自专栏Java与Android技术栈

用kotlin打印出漂亮的android日志(三)——基于责任链模式打印任意对象

SAF-Kotlin-log 是一个Android的日志框架,这几天我抽空重新更新了一下代码。

13610
来自专栏农夫安全

注入学习之sqli-labs-6(第五次)

前言 上一次课讲解的是sql基于布尔型盲注,紧接着这节讲基于时间的盲注 布尔型盲注,是在我们判断网站是否存在注入的时候,网页不会暴漏错误信息,但会返回正确的页面...

38360
来自专栏架构师之路

一分钟学awk够用(产品经理都懂了)

1分钟懂awk-技不在深,够用就行 1.什么是AWK (1)Aho、Weinberger、Kernighan三位发明者名字首字母; (2)一个行文本处理工具; ...

28950
来自专栏大内老A

ASP.NET MVC是如何运行的(3): Controller的激活

ASP.NET MVC的URL路由系统通过注册的路由表对HTTP请求进行解析从而得到一个用于封装路由数据的RouteData对象,而这个过程是通过自定义的Url...

23180
来自专栏Android-薛之涛

Android-Gson小总

几乎每次项目中都要用到Gson来解析json数据,今天想做个总结。ok,现在我们先来了解一下JSONObject和JsonObject的区别(我个人总结了三点)...

16430
来自专栏lgp20151222

springMVC框架的理解加深,个人的一些想法

写spring-boot整合的时候,有种想看源码的冲动!呸,是钻牛角尖的毛病犯了...

6420

扫码关注云+社区

领取腾讯云代金券