|
|
讨论过程中，有人认为assert检查的是bug, 而异常是可以恢复的意外情况。
所以，观点3的支持者说：可恢复的意外是可以理解的，但可恢复的bug就没什
么意义了。既然已经约定好了，你再违背，就属于是bug而不是意外了(比如打
不开文件什么的)。很多库函数都不检查指针的合法性(除了系统调用以外，因
为总不能让系统dump core吧)，也不检查指针是否为NULL(因为如果层层都检
查，必定劳民伤财，干脆让最上面调用的人在调用之外查)。
6、选择d+f
选f+d, 好处如下：
a以最激烈的方式，充分暴露调用都的错误！能及时修改BUG
b便于调试,问题出现后，直接到事故现场。比120还快！
c对于realse版的代码没有任何副作用。
d以处理的代价来看 采用断言也是编写最小一种。
e它是多语种，多平台所通用的方式， 如:C /C++ VB,Java1.4 在win ,unix
通吃, 便于移置!
如果在现实中，测试没有能找到所有的BUG,那可能就要用异常来帮忙了！
当然，我也提出了我的观点, 我支持观点6。理由如下：
assert只在debug标志的时候有用，而在编译release版本的时候不起作用。
assert对于检查硬编码的错误，是非常有用的，能够及时的查处编码的错
误。比如borland c++的类库源代码中就有很多这样的assert。但是assert
不是万能的，因为有很多错误的发生不是完全在编译时发生的，而是运行
时的错误。在release后，assert是不可能依赖的。那么，我们就需要
exception这一机制来检测运行时错误，并相应的做出处理。当然，在异常
检测和处理过程中还有许多需要讨论的问题，由于不是这一题目的范围，
我们没有必要继续讨论得太多，但是，提出来希望大家注意：异常不是捕
获了就完成任务了，而要对于不同的情况，采取不同的处理办法，千万不
能只是捕获，而不做任何处理，那样和不捕获异常没有任何区别。
在题目刚刚提出的时候，选择各种答案的人都有，所以，我有必要在这里把
其他答案为什么不能选的理由说一下。
(a) if (!pParam)
return 0;
这是很多初级程序员常常采取的一种方式。返回值设为0。 因为函数的返回
值往往是计算的结果，不赞成把错误标志值和计算结果混在一起使用，容易
造成使用者的误会。当然，在很多unix函数中，由于历史原因，还存在很多
这样子的函数，所以需要指出，不要沿用这种方式。
(b) if (!pParam)
return ERROR_PARAM;
b比a稍微好一点点，返回了一个常量或者预定义的宏。 从返回值的字面上，
调用者能知道发生了什么错误，但是，这也不是一种好的方法。
(c) if (!pParam)
pParam = "";
...
这是最不好的方式。直接给pParam赋予空字符串，然后继续函数过程，这
容易造成不可预料的后果，是程序不稳定的根源。
(d) if (!pParam)
throw EXCEPTION_ERROR_PARAM;
抛出异常，刚刚已经讨论过了，不再赘述。
(e) if (!pParam)
MessageBox(...);
这是一种比较可笑的方式，当然也有不少人用。MessageBox是直接弹出一个
对话框，告诉使用者，出错了。但是并不做任何处理，程序继续往下执行，
直到出错崩溃。呵呵
(f) assert(!pParam);
断言，刚刚已经讨论过了，不再赘述。
以上这个题目，引发了所有与会者的兴趣，讨论异常热烈，最后，主持人
也给出了自己的观点:d+f。当然这并不是标准答案，因为编程这一门课程
本来就没有什么标准答案，大家见仁见智，这个答案只是经验的积累。
主持人紧接着列出了"编写优质无错代码的经验":
a.理想的编译器和实际的编译器
b.使用断言
c.函数的界面设计
d.考虑风险
e.态度的问题
以上是本节的主要内容。断言，刚刚的问题中已经讨论过了，来看看其他的
内容。
理想的编译器和实际的编译器:
题目二：
下面memcpy函数实现有什么问题：
Void *memcpy(void *pvTo,void *pvFrom,size_t size){
byte *pbTo=(byte *) pvTo;
byte *pbFrom=(byte *)pvFrom；
while(size -- >0)；
*pbTo++= *pbFrom++;
return pvTo;
}
呵呵，粗略一看，这函数还真找不出问题来。但是仔细看看，你就会发现
while(size -- >0)；
这里多了一个分号，导致下面的*pbTo++= *pbFrom++;不是在while循环中
执行多次，而是只执行了一次。当然这不是函数设计者的预期结果，而编
译器却不会报告错误，因为while(size -- >0)；从语法上来讲，并没有
错误。这就是理想的编译器和实际的编译器的区别所在。
那么，该怎么检查这种错误呢？主持人提出了如下办法：
while(size -- >0) NULL; 可以加入NULL来解决空语句. 这样子，当你需
要 while(size -- >0)
*pbTo++= *pbFrom++;
这种形式的时候，就不会发生错误了，只需要用眼睛看看，就能发现了。
两点好处 1 无冗余代码，2 使人更明白。减少风险.
还有人会这么写
if( (n=read(....)) == 1) ....
在这里，赋值符号=和判断相等的符号==容易敲错，而编译器又检查不出来，
可能就会有如下错误：
If(ch = ‘ ’)...；这也是需要注意的问题。
理想的编译器和实际的编译器小结：
a.把屡次出错的合法的C习惯用法看成程序中的错误
b.增强编译器的警告级别
c.使用其它的工具来检查代码 如 Lint 等
d.进行单元测试
e.消除程序错误的最好方法是尽可能早、尽可能容易地发现错误，要寻求费力最小的自动查错的方法
f.努力减少程序员查错所需的技巧
使用断言
题目三
下面函数实现，哪一个好，为什么？
a.
char Uptolower(char ch){
if(ch >= ‘A’ && ch <= ‘Z’)
return ch+=‘a’-’A’;
return -1;
}
b.
char Uptolower(char ch){
assert(ch >= ‘A’ && ch <= ‘Z’)；
if(ch >= ‘A’ && ch <= ‘Z’)
return ch+=‘a’-’A’;
return ch;
}
c.
char Uptolower(char ch){
assert(ch >= ‘A’ && ch <= ‘Z’)；
return ch+(‘a’-’A’);
}
分析：
a.该函数检查ch是否在A..Z之间，如果是，则返回相应的小写字符，如果
|
|
| |
|
