断言究竟该如何使用

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

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

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

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

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

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

小结

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