同样有可能出错的地方,什么时候用异常处理,什么时候用手动检测,什么时候用断言,什么时候用#error,什么时候想尽办法避免使用者犯错误?

[menzi11]

同样有可能出错的地方,什么时候用异常处理,什么时候用手动检测,什么时候用断言,
什么时候用#error,什么时候想尽办法避免使用者犯错误?
这个问题说的就比较大了..诚心希望老师们花点时间说说自己的心得~:

简单的话,比如内存申请,申请失败自然是默认有异常产生的,
也见到有人用no throw的new来做,然后检测指针==nullptr.这两种用哪个可能习惯问题大于实际问题,
这种情况断言和#error显然是用不上的,也谈不上这段代码的使用者犯错误的问题...我的问题是例如下面
的情况或者更复杂的情况,我的问题包含且不只包含这个例子:


比如一个链表类List(我说的是自定义的不是标准库里的)
,和一个链表节点类ListNode.
可以把N个ListNode的实例连接到List中,并且通过自定义的迭代器访问,那么这时可能会出现这么几种错误:

1.用户在某处声明了一个List的实例,却没有在任何地方声明ListNode节点实例并添加入这个List,这种时候,
声明一个List的迭代器显然是不对的,因为List一直是空的


可能对于这三个类的设计者来说是不会范这种错误的,但对于这三个类的使用者,保不齐犯这种错误,
那么在我所知的情况下,能想到的有如下几种解决方案:

0.自己写的东西我自己用,所以我不会犯这种错误.
1.谁犯这种错误谁是白痴,所以不用管.
2.把注释和文档写明白点...

上面这三种肯定不是办法,下面几种更高级点:

3.把迭代器写的更加健壮,或者把node做成list里面的嵌套类,不让用户手动创建和销毁node,总之,通过
一切可能的代码方面的手段,避免这个问题的发生.

上面这种方法开发难度稍微增加了一点点,这不算大问题,但留给用户的自由性小了,
比如有的使用者就是想(无论任何原因)手动创建节点,就是想(无论任何原因)迭代器指向空list,
而且声称保证自己不会出错,这时怎么办?


3.如果list始终是空的,那么当迭代器指向这个list的时候,抛出一个异常
4.如果list始终是空的,那么当迭代器指向这个list的时候,检测一下然后返回个bool之类的东西.

上面这两种基本是一个东西了,总之就是在代码中加入一种检查机制.
虽然有效且安全,但影响代码的效率,实际上可能
一些方法根本就是throw(),但因为这种检查,不能不抛出异常.


5.加断言,出现类似问题的时候触发断点,debug的时候断了它!

这种方式好像更好点,release的时候就吧断言取消了就行了,但是假如某种情况即使是release下也
无法控制用户的行为,则意义变小了......


6.#error好像这个例子用不上....假如说能用吧,直接出问题的时候停止编译.

这个比较直接,但不是每个情况都能用它...



综上所述,对于可能出错的检查,总是有代价的,要么损失安全性,要么损失使用者的自由度,
要么影响程序的执行效率.而停止编译和断点的"强硬"方法并不是任何时候都能用...

我并不是问是否有针对上面例子的完美的解决方案,而是说,老师们对于类似这种问题,
是怎样把上面所述的几种可能的错误解决方案运用于案例中的.也就是我开头问的,
同样有可能出错的地方,什么时候用异常处理,什么时候用手动检测,
什么时候用断言,什么时候用#error,什么时候想尽办法避免使用者犯错误?
当然...扣工资等行政手段不算..


非常感谢!

[横云断岭]

可以参考这两篇文章：
http://blog.csdn.net/myan/article/details/1921
http://blog.csdn.net/myan/article/details/1922

我的看法是库尽量简单，错误多数由使用者处理。
对于用户，如果是合理的需求就帮用户完成。
比如发邮件，如果是一个发邮件的库，肯定是在发送发败就抛异常，或者返回-1 。
但是如果是一个客户端软件，那就通常会重试多次，直到发送成功。