【讨论】关于ASSERT断言,我从不使用。

[rabo]

ASSERT也许是一个很好的东西，断言一个必须成立的值。

但是我从来没有使用过，而是一直使用“老套”的返回值的方法，原因有以下几点：

1. ASSERT不能保证release下不出问题。

一个程序，里面可能会有各种各样的错误，一个十全十美的应用程序，是不可能的，毕竟人不是机器。这个时候，微软就提供了一个叫ASSERT的宏来判断一个值是否为假，并且在MFC源代码里面大肆狂用。这个宏很不错，让大家在DEBUG下能判断出假值。但是release下就判断不了了，当然你可以使用assert()函数，不过我们只讨论ASSERT宏。

有人说，只要DEBUG下断言成功了，RELEASE下就不会出错了。我们仅仅是希望如此而已。举一个例证明一下，内存溢出是所有会写代码的人都会遇到过的问题。你断言成功了，并不代表你内存不会溢出。这时，内存被踩了，谁都无法辨认，当然ASSERT它也不能。这个时候你的程序会继续向下执行，可能在很久之后才会出现错误。这无疑对你查找溢出点增加了很多难度。

如果你不是断言，而是使用的错误判断，很可能就在那一行代码就是查出错误，因为断言只能判断真假，而你的错误判断可以五花八门千变万化，并以错误码返回。当然可能有朋友会说这样会浪费性能，是，不过我更愿意些。

如果要继续举例，可以举出很多来。

2. 使用ASSERT提供的接口，我向来认为不好。

为什么要写这篇讨论，是因为我在网上看到了一们兄台的BLOG，其中有对ASSERT的讨论。http://www.cppblog.com/darkdestiny/archive/2006/07/15/10101.aspx其中有一段话让我想写这篇贴子。“因为我们写函数(接口)的目的,是希望能被正确的调用,而不是胡乱(导致局部或者整体状态混乱)的使用(为此我们居然要将assert写成错误处理的形式,以容忍各种白痴的调用行为).”

我不这样认为，我认为一个接口的提供者应该考虑到各种情况并且能够适应各种情况，这样的接口才是一个优秀的接口，也就是说随便你怎么折磨它都行。当然一个优秀的程序员，是应该仔细按照文档来编写代码，但是谁也不想一运行程序就“当”的一下弹出来错误吧。如果是MFC，至少还有代码可供你参考，你的接口如果没有代码，那别人很难知道是什么错误，因为ASSERT错误不会告诉什么值错了。更不用说RELASE版了，程序运行后会发生什么事，没人能知道。

这个时候如果你有错误返回值，那这一切都完美的解决了。开发人员可以一看返回值就知道是出了什么错误，这样多好，至少我这样觉得。


3. 目前看来，没有什么程序是必须必须要执行下去，而不能返回的。

ASSERT的作用就是在DEBUG里面帮你判断，RELASE里面不管你，也就是在DEBUG里面，值一定要正确，然后执行下去，RELEASE里面无论有不有值程序都将执行下去。我想，应该不会有什么函数是要求不管有不有错误都必须执行下去吧。难道就不能给出一个返回值来告诉作者哪里出错了吗？

在此我置疑MFC里面那大篇大篇的ASSERT。


4. 上面的都是我的一些看法和观点，可以比较狭隘和偏执。希望大家热烈讨论，如果觉得我不对，请说出使用它的理由来，并举例说明，谢谢。我也很希望知道是我自己错了，一般还是不要怀疑微软的东西比较好。

[daymist]

ASSERT的好处很多。很方便地可以展现DEBUG版本的错误，且不会出现在RELEASE版本中，不影响代码质量和速度。为什么不用呢

[clever101]

1. ASSERT不能保证release下不出问题。


................

个人认为ASSERT只用于DEBUG版本，是因为它本身是被设计为用于调试，不是为了保证release版本出不出问题。

[WingForce]

不使用ASSERT在开发阶段和测试阶段如何发现潜在的问题，应该会比较麻烦吧
还是就下面这个问题讨论：

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

如何才能使程序获得一个正常的流程.
比如这段程序如果传空值,在RELEASE下就会出错,这个就是你讲的流程出错么,我暂时这么理解的哈.

int fun(char *buf)
{
ASSERT(buf);
}


那如果要正确的流程不是还要加上这个判断呢?
int fun(char *buf)
{
ASSERT(buf);
if(NULL == buf)
return xxx;
}


那为什么不能直接就这样呢?
int fun(char *buf)
{
if(NULL == buf)
return xxx;
}

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

因为在测试阶段
int fun(char *buf)
{
if(NULL == buf)
return xxx;
}
是可以正常“工作”的，而其产生的影响可能会藏的很深，比如说是造成最终给用户显示的某个值
错了，这些都是很难在测试阶段发现的。
而使用ASSERT能快速而准确的定位这中问题

[king820802]

断言我来说两句吧

以前我也从来不使用断言，因为觉得断言完全可以拿防错（返回值）来替代。
但是我现在经常使用断言，做个很简单的比方：
void Func(char *pchText)
{
ASSERT(NULL != pchText);
}
像上面，你拿个返回值去判断，的确做到防错了。但是却很容易忽略了错误的存在性。也就是说，只要pchText存在，函数一定成功（不包含特意的拿别的指针强制转化成 char*）。这样就不用对返回值进行判断了，减少了工作量了

[king820802]

当然不能拿断言替换所有的防错，两种都存在，都要好好使用。
什么时候用断言，什么时候用防错。必须协调好

[liubin0509]

學習

[ybss]

哈哈，我就经常用，通常用在函数的参数检查和不应该到达的程序分支，在代码中存在也有助于理解程序的意图。
而且实践中也得到了很多好处，单元测试的时候可以捕获到很多低级的错误，并不像楼主说的那样没有必要。

[nonocast]

所以.NET的framework就使用异常机制,MS自己也在update这些设计
你可以对比一下MFC和dotfx,差太多了
单纯从使用的fx上来说,dotfx程序要比mfc好太多,至少不会因为一个ASSERT,导致全盘皆输

一个小错就要了ASSERT的命了,在release中不能及时反映出错误的存在,以至后续出错

我很同意lz的观点,但在21世纪提出来似乎晚了一点
从Java,到C#到Ruby,ASSERT几乎已经淡出,设计理念距离MFC形成巨大的差距,不过太多太多的人都没有注意到错误机制的重要性

呵呵

[rabo]

终于有一个支持者了

[olncy]

学习，因为不会用，所以没有用

[tiger波波]

学习

[珍惜生命远离CPP]

assert还是比较好用的东东，虽然我用的也不怎么多。

[rabo]

感谢大家讨论.
得出了一个结论.
就是ASSERT和判断一起用就比较完美了.
int fun(char *buf)
{
ASSERT(buf);
if(NULL == buf)
return xxx;
}

但是这也说明上面有些论据的不对,比如说"节约了代码量"

[nonocast]

我感觉用异常会更好一些

[rdsnow]

我不会用

[rabo]

再顶起来让大家看看.说不定能学到点东东.星期一结贴.

[newcore]

“请注意ASSERT不是容错的处理方式，它是为了方便调试错误、判断出错原因的。”

这句话应该是对ASSERT很好的诠释了。

ASSERT当然不能也不能暴露程序运行时的所有问题，记得一句话：“ASSERT放在你认为不可能出错的地方”不失为一个好的习惯而已。

[nonocast]

but你觉得有不可能吗?

[nonocast]

如果真的不可能错,加入ASSERT岂不是拖了裤子放P
好好想想吧
写ASSERT意味着需要对如果的错误进行处理
而且随着软件的规模庞大,测试的力度有多大,可以把引起ASSERT的bug找出来

一旦没有测试力度,那么ASSERT将直接暴露给用户
用户会看到一个ugly的Assert Fail
我看了都会吓一跳,release以后则错误成了定时炸弹,错了以后也不知道错在哪里,连日志都没有,惨

[GG坏蛋宝宝]

我遇到同样问题，程序使用了assert，在程序运行一段不确定时间后，突然退出，日志都没有，惨啊。
我感觉调试阶段用用assert还可以，在正式版后，要删除assert，改写成容错机制。
int fun(char *buf)
{
//ASSERT(buf);
if(NULL == buf)
return xxx;
}