断言究竟该如何使用

Posted by LuckXiang on December 26, 2018

在开发过程中,我们通常会遇到三种错误:用户错误,异常以及运行时错误。用户错误和异常都好处理,编写对应的处理程序即可。运行时错误就要麻烦很多,由于运行时错误是一种BUG,一般来说发现就必须处理,编写专门的处理代码似乎没有太多意义。于是大多数语言都提供了断言来帮助我们诊断运行时错误。关于断言的争论网上有很多,有的人说断言很有用,有的人说断言会带来额外的麻烦,尽量不要用。有的人说断言生产环境应该关掉,理由是运行速度更快,有的人说断言应该保留到生产环境中,相比断言的好处,运行效率的影响很小。这个问题曾经深深的困惑着我,下面我我来说一下我对这个问题的看法,希望能对困惑的人有些许启发。

断言是一种优秀的调试手段

我的观点很明确,断言是一种优秀的调试手段,它可以很好的与其他调试工具,如gdb等一起发现程序中的逻辑错误。而且调用简洁,在生产环境中可以很方便的关掉,利用断言可以写出更优美、更容易调试的代码。反对使用断言的人一般有以下几种观点,我来一一反驳:

  • 断言和if很像,可以用if替代。(调试代码不应该引入系统变成生产代码的一部分,当代码逻辑没问题的时候,if代码的存在没有任何意义)
  • 单元测试比断言更好。 (单元测试和断言的目的不一样,单元测试主要是为了检测模块的行为是否符合预期,是一种测试机制。而断言是一种辅助调试手段,问题不一定是测试的模块导致的,也有可能是其他模块引入的。所以单元测试不能代替断言。)
  • 断言失败会导致程序退出。(调试就是为了发现问题,退出是合理的)
  • 在断言中写入业务逻辑可能会导致问题。(断言不能用于生产环境,写入业务逻辑就是一种错误的行为)

断言不应该用于生产环境,但是原因不是基于执行效率去考虑

在我看来,断言作为一种调试手段,绝对不能用于生产环境。开发者需要考虑到程序执行出错时关键资源,如数据库,文件等的安全性。另外生产环境的问题跟踪,也有日志,监测工具等更好的选择。正如我们所看到的那样,断言放入生产环境,失败程序直接退出导致严重故障,同时也容易麻痹程序员,引起滥用断言,导致业务逻辑进入断言等问题。至于断言的执行效率,我觉得在这里根本不值得考虑。

小结

  • 断言不能用于生产环境
  • 断言不能写入业务逻辑
  • 开发者需要自己保护关键资源的安全,如文件数据库等,不能依赖断言
  • 理解断言的使用场景,必须要搞清楚用户错误,异常和运行时错误的区别
  • 总的来说,断言只是一种辅助调试手段,异常、安全等开发者需要考虑的设计问题不能用断言处理