断言究竟该如何使用

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

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

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

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