再谈Assert

 ASSERT是一个多么让人熟悉的单词，几乎所有学习C++的人都看到过它，但是它的价值在在今天的.net时代似乎被忽略了。

最近在看一本关于如何debug的书，里面提到了assert，让我从新意识到它的存在价值。

这一个月以来，我尽量在我编写的代码中使用Debug.Assert，发现它的好处颇多。

1. 不会对程序造成负面影响

2. 能够很好的保护你的代码逻辑

3. 能够在一定程度上抵消不好的程序设计带来的影响

4. 能够让代码重构变得更加安全。

下面我将对上面4点作更详细的阐述。

1. Assert对程序不会造成负面影响，它只会在debug版本中发挥作用。我们使用Assert的最终目的是尽量早的发现系统中出现的问题，而不是等到这个问题在系统中的某个地方执行不下去的时候。不管是面向对象，面向组件还是面向服务，所有的问题最终都要转化为流程来解决。能够在流程中越早发现问题，解决这个问题的难度就越小。所以，如果你是一个偏执狂，你甚至可以为每一行代码加上assert，当然这太极端了，如果你想在Assert量和代码质量之间找到一个平衡点，可以参考一下我推荐的那本书。

2. 这个有点是基于第1点的。由于Assert不会对程序造成负面影响，那么你可以为每一段重要的代码逻辑编写Assert。在这个位置，Assert和Exception的区别非常微妙，我还没有完全搞清楚，但是目前为止，还是放心的加上Assert吧，因为它对程序不会造成任何负面影响。但Assert保护代码逻辑体现在什么地方呢，下面的一段简单的代码足可以说明问题？

Debug.Assert(mServicePointDetailData != null, "service point manual data is null");                ServicePointType selectedObj = lists.Find(n => n.ServicePointTypeKey == mServicePointDetailData.PSServicePointTypeKey);                Debug.Assert(selectedObj != null, "invalid service point detail key");                ddlServicePointType.SelectedIndex = lists.IndexOf(selectedObj);                mTypeName.Text = mServicePointDetailData.PSTypeName;

在上面这段代码中，对mServicePointDetailData 的Assert，就是对下面代码的保护。在当前的上下文中，mServicePointDetailData不应该为null，如果它为空，说明程序的其它地方出问题了。我个人强烈推荐一边写代码，一边给你认为重要的代码加上Assert,特别是在维护已经存在的系统的时候，因为在这种环境下，你是不可能100%的保证你修改或插入的业务逻辑能够在已有的系统中正常运行，所以这个时候你应该谨慎，通过充分的Assert来保证你修改的代码能够正常运行。假设你的Assert截获了错误信息，那这个时候至少说明两个问题：1. 代码执行的上下文中，有你没有考虑到的情况，也许你应该将这个Assert去掉，调整你的当前代码，使其可以处理当前的这种情况；2. 输入数据有问题，你应该通过CallStack去寻找问题出在什么地方。

另外，就算是你在从事一个新系统的开发，Assert的使用也是必要的，通常在高强度的工作压力下，你可以100%的肯定你在当前函数中使用的输入参数或是成员变量被正确初始化了吗？

3. 这一点其实也是基于第2点。设计得不是很好的程序，有一个特点，就是成员变量满天飞。当代码量变得越来越庞大的时候，你随时都有可能使用到状态不正确的成员变量。这个时候，你可以使用Assert将你当前要使用的数据保护起来，从而打消成员变量状态不正确的忧虑。接下来你要做的就是运行程序，如果Assert截获了错误信息，那么也没什么大不了的，调整代码--至少这一切还处于你的控制之中。

4. 这一点其实也是基于第3点。充分的Assert信息可以帮助代码重构者了解当前这段代码运行的前提，从而尽量避免因代码重构引入新的bug。

以上是个人对Assert的一点浅薄的体验，还望各位多多分享你们Debug的经验。

哦，对了我提到的那本书，叫

Debugging Microsoft® .NET 2.0 Applications，
作者：John Robbins
 大家可以到我的资源去下载