避坑：不要在调试版本中的修改程序逻辑
source link: https://www.51cto.com/article/769416.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
避坑：不要在调试版本中的修改程序逻辑
作为一名开发者，我想，你最不希望发生的事情之一是：当你调试一个Bug的时候，Bug就消失了，但直接运行的时候，Bug又出现了。
通过 #ifdef DEBUG 技法，可以将额外的调试代码放置到程序中。毕竟，这些调试代码仅会在程序的调试版本中才会生效。但是，一定要注意的是，这些调试代码不应该修改程序的执行逻辑。
你可以在调试代码中执行参数验证，执行断言，追踪资源的使用，这可能会降低程序的性能并消耗更多的计算资源，这些都是可以接受的，唯一需要注意的一条是：不要在调试代码中修改程序的流程。
我们来看看下面的例子。
上面的代码是错误的，你是否已经看出来了？
调试版本的行为与发行版本根本不同。如果有人使用 NULL 为 p 参数调用此函数，则程序的发行版本将崩溃，但调试版本将捕获错误并使调用失败。
不要在调试版本中修改函数的语义。如果发行版本崩溃，则调试版本也必须以相同的方式崩溃。当然，你可以在崩溃之前记录错误日志信息，但你仍然需要它”崩溃”，和发行版本行为保持一致。
下面是一个展现了类似问题的 C# 代码的例子。
在上面的例子中，调试版本记录并吞掉了异常，而发行版本直接让异常跳出了此函数。
如果你恰好也写了这样的代码，发行版本和调试版本的行为方式根本不同，你最终会陷入这种情况：发行版本有一些问题，但调试版本工作正常。
你的客户无法弄清楚有什么区别，因此他们切换到生产服务器上的调试版本。它的运行速度是原来的两倍，内存消耗的内存是原来的三倍，需要大量的资源才能扩展到以前的服务级别。但这是他们能做的最好的事情，因为问题不会出现在调试版本上（因此无法在那里调试）。
我看到过关于软件陷入这种困境的报道，这对开发人员的影响非常糟糕。
今天的论点也是我一直所忽视的：调试的代码，就干调试的活，不要做其他事情，更不要修改程序执行流程。
第二个：调试版本和发行版本可能在执行速度，占用资源存在差异，但两者的行为必须完全一致。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK