编写优质无错代码

一种反对d的理由

　　不可用d, 这就像你用人,却不相信人一样,偏要try,catch防范他。其实那个错是自己造成的,如果看到异常就容易不检讨自己。

关于观点3的支持意见

　　讨论过程中，有人认为assert检查的是bug, 而异常是可以恢复的意外情况。所以，观点3的支持者说：可恢复的意外是可以理解的，但可恢复的bug就没什么意义了。既然已经约定好了，你再违背，就属于是bug而不是意外了(比如打不开文件什么的)。很多库函数都不检查指针的合法性(除了系统调用以外，因为总不能让系统dump core吧)，也不检查指针是否为NULL(因为如果层层都检查，必定劳民伤财，干脆让最上面调用的人在调用之外查)。

选择d+f

　　选f+d, 好处如下：

1. 以最激烈的方式，充分暴露调用都的错误！能及时修改BUG
2. 便于调试,问题出现后，直接到事故现场。比120还快！
3. 对于realse版的代码没有任何副作用。
4. 以处理的代价来看 采用断言也是编写最小一种。
5. 它是多语种，多平台所通用的方式， 如: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。当然这并不是标准答案，因为编程这一门课程本来就没有什么标准答案，大家见仁见智，这个答案只是经验的积累。

　　主持人紧接着列出了"编写优质无错代码的经验":

1. 理想的编译器和实际的编译器
2. 使用断言
3. 函数的界面设计
4. 考虑风险
5. 态度的问题

　　以上是本节的主要内容。断言，刚刚的问题中已经讨论过了，来看看其他的内容。

题目二：理想的编译器和实际的编译器:

　　下面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++;

　　这种形式的时候，就不会发生错误了，只需要用眼睛看看，就能发现了。两点好处：无冗余代码，使人更明白。减少风险.

　　还有人会这么写

if( (n=read(....)) == 1) ....

　　在这里，赋值符号=和判断相等的符号==容易敲错，而编译器又检查不出来，可能就会有如下错误：

If(ch = ‘ ’)...；这也是需要注意的问题。

　　理想的编译器和实际的编译器小结：

1. 把屡次出错的合法的C习惯用法看成程序中的错误
2. 增强编译器的警告级别
3. 使用其它的工具来检查代码 如 Lint 等
4. 进行单元测试
5. 消除程序错误的最好方法是尽可能早、尽可能容易地发现错误，要寻求费力最小的自动查错的方法
6. 努力减少程序员查错所需的技巧

题目三：使用断言

　　下面函数实现，哪一个好，为什么？

a.
char Uptolower(char ch){
if(ch >= ‘A’ && ch <= ‘Z’)
return ch+=‘a’-’A’;
return -1;

 如果您对本文有任何疑问或者建议，请到讨论区发表您的意见: >> 论坛入口 <<

上一页 1 23 下一页

上一篇：一个被入侵网站分析报告   下一篇：系统恢复指南

【文章评论】 【收藏本文】 【推荐好友】 【打印本文】 【我要投稿】 【论坛讨论】