大家在项目代码中会大量使用断言么？

Kevin_zqw

我对于一些绝对不应该出现的情况，会使用断言

但使用得不是特别多。

orclover

虽然偶学生，缺少实际项目经验，但是看了大家的发言，有以下看法：
断言该用还是要用。而且我觉得应该是很有用的。
因为我觉得错误处理，根本不可能完全代替断言。这里可以大体分两种情况：

一种是，就像那个字符串复制的例子，字符串复制在一个项目里属于基础库，因为其完成的功能具体而微，所以我们可以相对容易的预见，使用者可能会犯什么样的错误。这时，使用断言，或者错误处理，起码都能达到捕捉参数错误的目的。不过感觉那个字符串复制的例子，关键还是要放到具体情境中理解，关键就在于，如果使用者传递了NULL指针，到底是关键错误，还是一般错误。如果是一般错误，可能没必要使用断言。（不过关于参数错误，我个人更倾向于使用断言，以前写函数的时候也考虑过这个问题，就是哪些应该是函数使用者的责任，哪些应该是函数的责任。具体到字符串复制，我觉得保证参数的有效性，应该是使用者的责任）

还有一种就是，你根本不可能预见错误的发生，也就是这里的错误可能完全是逻辑错误，只有程序逻辑编写出错的时候，才会发生这种错误。如果你根本想不到这种错误，无法预见，何谈错误处理呢？比如有个课的老师（在IBM工作）说他写一个多线程程序，因为多线程程序很难调试，程序偶尔会出现错误，也就是这种错误可能运行N多次才会出现一次，搞的他很郁闷。到最后搞了几天几夜，他几乎都要投降了，就去睡了一觉，睡醒后又看代码，突然裸看出来一个逻辑错误。也就是有个地方产生了一个错误的数据，传递给另一个函数处理，另一个函数默认其传进来的参数应该具备某个特征，也就是你根本不可能想象传递进来的数据不具备这个特征。由此他有两个感慨：人应该劳逸结合；要是这里使用断言就好了。由此可见，断言还是很有用的。

断言感觉还是很有用的。

[ 本帖最后由 orclover 于 2008-7-2 16:57 编辑 ]

benjiam

还有一种就是，你根本不可能预见错误的发生，也就是这里的错误可能完全是逻辑错误，只有程序逻辑编写出错的时候，才会发生这种错误。如果你根本想不到这种错误，无法预见，何谈错误处理呢？比如有个课的老师（在IBM工作）说他写一个多线程程序，因为多线程程序很难调试，程序偶尔会出现错误，也就是这种错误可能运行N多次才会出现一次，搞的他很郁闷。到最后搞了几天几夜，他几乎都要投降了，就去睡了一觉，睡醒后又看代码，突然裸看出来一个逻辑错误。也就是有个地方产生了一个错误的数据，传递给另一个函数处理，另一个函数默认其传进来的参数应该具备某个特征，也就是你根本不可能想象传递进来的数据不具备这个特征。由此他有两个感慨：人应该劳逸结合；要是这里使用断言就好了。由此可见，断言还是很有用的。

如果多线程代码 加了断言调试不出来，也是有可能， 在调试这里看不到情况。

在客户那里才会出现一次，而且很可能只有客户某些硬件环境才会出现和重现，这种情况只有靠日志和3 的返回值判断才能解决。

orclover

嗯，很有道理。产品运行时会发生什么，确实不好预计。你的话，让我想起另外一个老师的话，对于已经交付给客户运行的程序，日志很重要。

caijimin

shan_ghost 不但技术精湛，而且文采飞扬，佩服

77h2_eleven

原帖由 Kevin_zqw 于 2008-7-2 15:57 发表
我对于一些绝对不应该出现的情况，会使用断言

但使用得不是特别多。

我个人也觉得是这样。注意“绝对”两个字。

aero

目前接手的项目中没有大量使用断言。

HW的项目中存在大量断言。非常好。虽然也骂，但HW的代码质量还是不错的。

自己倾向大量使用断言。

77h2_eleven

原帖由 aero 于 2008-7-3 10:56 发表
目前接手的项目中没有大量使用断言。

HW的项目中存在大量断言。非常好。虽然也骂，但HW的代码质量还是不错的。

自己倾向大量使用断言。

HW 的项目是这样？看来真的达到了一定的高度。这几年超过ZTE这么多也不是偶然。

BTW：HW在沈阳也有研究所？

aero

原帖由 77h2_eleven 于 2008-7-3 11:47 发表

HW 的项目是这样？看来真的达到了一定的高度。这几年超过ZTE这么多也不是偶然。

BTW：HW在沈阳也有研究所？

没有，BJ的。