C++异常处理机制核心观点

C++异常处理机制核心观点:

0.如果使用普通的处理方式:ASSERT,return等已经
   足够简洁明了,请不要使用异常处理机制.

1.比C的setjump,longjump优秀.

2.可以处理任意类型的异常.
   你可以人为地抛出任何类型的对象作为异常.
   throw 100;
   throw "hello";
   ...

3.需要一定的开销,频繁执行的关键代码段避免使用
   C++异常处理机制.

4.其强大的能力表现在:
   A.把可能出现异常的代码和异常处理代码隔离开,结构更清晰.
   B.把内层错误的处理直接转移到适当的外层来处理,化简了处理
     流程.传统的手段是通过一层层返回错误码把错误处理转移到
    上层,上层再转移到上上层,当层数过多时将需要非常多的判断,
    以采取适当的策略.
   C.局部出现异常时,在执行处理代码之前,会执行堆栈回退,即为
     所有局部对象调用析构函数,保证局部对象行为良好.
   D.可以在出现异常时保证不产生内存泄漏.通过适当的try,catch
     布局,可以保证delete pobj;一定被执行.

   E.在出现异常时,能够获取异常的信息,指出异常原因.
     并可以给用户优雅的提示.
   F.可以在处理块中尝试错误恢复.保证程序几乎不会崩溃.
     通过适当处理,即使出现除0异常,内存访问违例,也能
     让程序不崩溃,继续运行,这种能力在某些情况下及其重要.

以上ABCDEF可以使你的程序更稳固,健壮,不过有时让程序崩溃似乎更
容易找到原因,程序老是不崩溃,如果处理结果有问题,有时很难查找.

5.并不是只适合于处理'灾难性的'事件.普通的错误处理也可以用异常机制
   来处理,不过如果将此滥用的话,可能造成程序结构混乱,
   因为异常处理机制本质上是程序处理流程的转移,不恰当的,过度的转移显然
   将造成混乱.许多人认为应该只在'灾难性的'事件上使用异常处理,以避免异常
   处理机制本身带来的开销,你可以认为这句话通常是对的.

6.先让程序更脆弱,再让程序更坚强.首先,它使程序非常脆弱,稍有差错,马上
   执行流程跳转掉,去寻找相应的处理代码,以求适当的解决方式.
   很像一个人身上带着许多药品,防护工具出行,稍有头晕,马上拿出清凉油;
   遇到蚊子立刻拿出电蚊拍灭之.

WINDOWS:
7.将结构化异常处理结合/转换到C++异常对象,可以更好地处理WINDOWS程序
   出现的异常.
8.尽一切可能使用try,catch,而不是win32本身的结构化异常处理或者
   MFC中的TRY,CATCH宏.

用得恰到好处,方显C++异常之美妙!catch(…)
{
}
这三个点并不是说要省略什么.相反,你需要在程序中实际输入这三个点.这是一个很好的默认CATCH块,应该把它放在其他所有CATCH块之后.

17.1.7异常规范:
Double safe_divide(int top,int bottom) throw(DivideByZero);
假如在函数中抛出一个异常,但异常规范中并未列出这个异常(也没有在函数内部捕捉),会发生什么事情?在这种情况下,程序会终止.尤其要注意的是,假如一个异常在函数中招聘但既没有在异常规范中列出,也没有在函数内部捕捉,那么它不会被任何catch块捕捉,而是直接导致程序终止.记住,如果完全没有异常规范列表,就连空白的都没有,那么效果等同于在规范列表中列出所有异常.在这种情况下,抛出一个异常不会终止程序.
注意,异常规范是为那些准备跑到函数外部的异常而准备的.如果它们不跑到函数外部,就不归入异常规范.如果它们要跑到函数外部,就应该归入异常规范,无论它们起源于何处.如果在函数定义内部的一个try块中抛出一个异常,而且在函数定义内部的一个catch块中捕捉这个异常这个异常的类型就不需要在异常规范中列出.如果函数定义包括对另一个函数的调用,而另一个函数可能招聘一个它自已不会被捕捉的异常就应该在异常规范中列出异常的类型.

要表示一个函数不应抛出任何不在函数内部捕捉的异常,需要使用一个空白异常规范.
Void some_function() throw();
几种方式可以总结如下:
Void some_funtion() throw(DivideByZero,OtherExecption);
//DivideByZero或OtherException类型的异常会被正常处理.
//至于其他任何异常,如果抛出后未在函数主体中捕捉,就会终止程序.
Void some_function()throw();
//空异常列表:一旦抛出任何未在函数主体中捕捉的异常就会终止程序.
Void some_function();
//正常处理所有类型的所有异常.
17.1.8陷阱:派生类中的异常规范
在派生类中重定义或覆盖一个函数定义时,它应具有与基类中一亲友的异常规范,或至少应该在新的异常规范中给出基类异常规范的一个子集.换言之,重定义或覆盖一个函数定义时,不可在异常规范中添加新异常.但是,如果愿意,可删减基类中原有的异常.之所以有这个要求,是因为在能够使用基类对象的任何地方,都能使用一个派生类对象.因此,重定义或覆盖的函数必须兼容于为基类对象编写的任何代码.

下面的内容是我从<<C++面向对象程序设计(第五版)>>找到值得学习的内容
assert语句
我们曾用以下语句测试一个名为in_stream的文件是否成功打开:
If(in_stream.fail())
{
Cout<<”input file opening failed./n”;
Exit(1);
}
可用assert(断言)语句编写同样的测试,如下所示:
assert(!in_stream.fail());
注意,这种情况下,我们要插入一个求反操作符(!),才能获得同样的效果,因为我们要断言的是文件打开操作”没有失败”.
Assert语句由标识符assert,一个逻辑表达式(包含在一对圆括号内)各一个分号构成.可以使用任何逻辑表达式.如果逻辑表达式false,程序就终止运行,并给出一个错误消息.如果逻辑表达式示值为true,就什么情况都不会发生,程序继续执行assert语句之后的下一条语句.因此,assert 语句是在程序中进行错误检查的一种精简方式.
Assert语句在cassert库中定义,所以使用assert语句的任何程序都必须包含以下include预编译指令:
#include<cassert>
Assert是一个宏(类似于函数的一种结构),所以有必要在一个库中定义它.
使用assert语句的一个好处是可以将其关闭.你可在自己的程序中用assert语句来高度程序,再将其关闭使用户看不到他们无法理解的错误消息.关闭assert语句,还能减少程序执行这些语句的开销.要关闭程序中的所有assert语句,请在include预编译指令之前添加#define NDEBUG,如下所示:
#define NDEBUG
#include<cassert>
因此,如果在进行了全面高度的程序中插入#define NDEBUG
,就会关闭程序中的所有assert语句.如果以后改动了程序,可删除程序中的#define NDEBUG重新打开assert语句第6点补充为:
6.先让程序更脆弱,再让程序更坚强.首先,它使程序非常脆弱,稍有差错,马上执行流程跳转掉,去寻找相应的处理代码,以求适当的解决方式,如果找不到任何解决办法(异常没有被捕获并处理),立刻(结束程序运行).
很像一个人身上带着许多药品,防护工具出行,稍有头晕,马上拿出清凉油;遇到蚊子立刻拿出电蚊拍灭之,遇到哪怕是蚊虫叮咬,如果找不到电蚊拍,他马上自杀!(这个家伙真是脆弱:) 以致于我们必须为他准备所有的防护工具一旦我们为他准备了全部适当的防护工具,他就变成一个非常坚强的人了!).
当然,代价是这个家伙变得比较笨重,行动迟缓,