讨论！！！

HopeCao

　　作为开发团队的一员，你需要实现一些库函数提供给其他人使用。假设你实现的一个函数原型如下：

1. 
   
2. int DoSomeThing(char* pParam)
   
3. {
   
4. ...
   
5. }
   

复制代码

　　你们约定好参数pParam不能为NULL，但为了防止调用者错误传递NULL，你需要在你的函数里做判断处理。

　　请问你会选择那种方式，并说明原因？

1. 
   
2. (a) if (!pParam)
   
3. return 0;
   
4. 
   
5. (b) if (!pParam)
   
6. return ERROR_PARAM;
   
7. 
   
8. (c) if (!pParam)
   
9. pParam = "";
   
10. ...
    
11. 
    
12. (d) if (!pParam)
    
13. throw EXCEPTION_ERROR_PARAM;
    
14. 
    
15. (e) if (!pParam)
    
16. MessageBox(...);
    
17. 
    
18. (f) assert(!pParam);
    
19. 
    

复制代码

pcerma

1）比较通用的方法应该是a和b，提供给调用者自己判断，
在这样的方式下，需要调用者知道函数的返回值的意义，
所以需要在开发者之间进行很好的协调。函数提供者
函数需要对函数进行明确的注释。

2）c的做法我不会选择，因为给lParam赋一个空字符串，
然后做一个没有意思的执行，做法不是很合适；

3）e的做法不很通用，写出来的函数不能适应所有环境；

4）我倒是喜欢用d的做法，函数调用者在catch中解决函数
异常。
   使用try，catch是一个比较好的方法，一些商用的API
一般都提供比较强的异常处理功能。

hopecao，不知你喜欢使用什么方式？？

gadfly

呵呵，这好像是C考试题中的一道。

C里面通用的做法是f。

beggar

F
1. 开发
2. easy

beggar

F
1. 开发
2. easy

stanleylei

好像一般都是用f，除非你检测到还要进行一些别的处理

HopeCao

这是问题提出者的选择： 选择d+f。
    　　assert只在debug标志的时候有用，而在编译release版本的时候不起作用。assert对于检查硬编码的错误，是非常有用的，能够及时的查处编码的错误。比如borland c++的类库源代码中就有很多这样的assert。但是assert不是万能的，因为有很多错误的发生不是完全在编译时发生的，而是运行时的错误。在release后，assert是不可能依赖的。那么，我们就需要exception这一机制来检测运行时错误，并相应的做出处理。当然，在异常检测和处理过程中还有许多需要讨论的问题，由于不是这一题目的范围，我们没有必要继续讨论得太多，但是，提出来希望大家注意：异常不是捕获了就完成任务了，而要对于不同的情况，采取不同的处理办法，千万不能只是捕获，而不做任何处理，那样和不捕获异常没有任何区别。