避坑：不要在调试版本中的修改程序逻辑

作为一名开发者，我想，你最不希望发生的事情之一是：当你调试一个Bug的时候，Bug就消失了，但直接运行的时候，Bug又出现了。

通过 #ifdef DEBUG 技法，可以将额外的调试代码放置到程序中。毕竟，这些调试代码仅会在程序的调试版本中才会生效。但是，一定要注意的是，这些调试代码不应该修改程序的执行逻辑。

你可以在调试代码中执行参数验证，执行断言，追踪资源的使用，这可能会降低程序的性能并消耗更多的计算资源，这些都是可以接受的，唯一需要注意的一条是：不要在调试代码中修改程序的流程。

我们来看看下面的例子。

>> 请移步至 topomel.com 以查看图片 <<

上面的代码是错误的，你是否已经看出来了？
调试版本的行为与发行版本根本不同。如果有人使用 NULL 为 p 参数调用此函数，则程序的发行版本将崩溃，但调试版本将捕获错误并使调用失败。

不要在调试版本中修改函数的语义。如果发行版本崩溃，则调试版本也必须以相同的方式崩溃。当然，你可以在崩溃之前记录错误日志信息，但你仍然需要它”崩溃”，和发行版本行为保持一致。

下面是一个展现了类似问题的 C# 代码的例子。

>> 请移步至 topomel.com 以查看图片 <<

在上面的例子中，调试版本记录并吞掉了异常，而发行版本直接让异常跳出了此函数。

如果你恰好也写了这样的代码，发行版本和调试版本的行为方式根本不同，你最终会陷入这种情况：发行版本有一些问题，但调试版本工作正常。

你的客户无法弄清楚有什么区别，因此他们切换到生产服务器上的调试版本。它的运行速度是原来的两倍，内存消耗的内存是原来的三倍，需要大量的资源才能扩展到以前的服务级别。但这是他们能做的最好的事情，因为问题不会出现在调试版本上（因此无法在那里调试）。

我看到过关于软件陷入这种困境的报道，这对开发人员的影响非常糟糕。

总结

今天的论点也是我一直所忽视的：调试的代码，就干调试的活，不要做其他事情，更不要修改程序执行流程。
第二个：调试版本和发行版本可能在执行速度，占用资源存在差异，但两者的行为必须完全一致。

最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。
本文来自：《Do not change program semantics in the debug build》