《C++ Primer》笔记之异常处理

大佬教程收集整理的这篇文章主要介绍了《C++ Primer》笔记之异常处理，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。

 @H_801_1@

一、抛出异常

      当程序发生异常的时候可以用throw语句抛出异常对象，抛出的异常对象由throw以后的实际对象所决定。假设有这样一个异常类继承层次结构：基类是excep并从他派生出@L_313_0@mathexc异常对象，当声明了一个excep指针pe，则语句throw *pe将抛出一个excep异常对象，无论pe实际指向的对象是excep或是mathexc类型。

      抛出异常的过程可以这样描述：1.创建一个临时的异常对象；2.将这个临时的异常复制到异常储存区；3.调用析构函数销毁掉先前创建的临时对象；3.抛出异常储存区中的异常对象。这个抛出过程意味着即使将一个已经定义的全局的异常类对象用在throw语句中，实际被抛出的异常对象只是这个全局对象的一个拷贝，在catch语句中对这个异常对象的任何操作都不会引起全局对象的改变。

二、try块

      使用try块告诉程序这个代码块可能会抛出异常。try块将形成一个局部域。try块可以包括一个函数定义中的某些代码段，也可以包括整个函数定义。当try块包括整个函数定义时只要将try放在函数的参数表之后（类的const成员函数则放在const之后）。如：int main() try{/*...*/}

      当try块被用在类的构造函数中时，并且想要捕获类对象构造期间抛出的异常则try应该放在构造函数参数表和成员初始化列表之间。如：istack::istack(int sizE) try :_size(sizE) {/*...*/}

三、捕获异常

       可以使用catch语句来捕获异常，catch语句中的参数就像函数的参数表一样。在捕获异常时catch语句根据其出现的先后次序尝试进行匹配，如果一个catch语句被匹配则之后的catch语句都将不再被考虑。这和函数的重载解析有所区别，函数的重载解析将考虑所有在调用点可见的函数声明并找出一个最佳可行函数；而CAtch语句仅仅是按照先后持续进行匹配，匹配后即使后续的catch语句有比当前catch语句更匹配的语句也不被考虑。

      在尝试catch语句匹配时不允许除派生类到基类对象或派生类指针、引用到基类指针、引用以外的一切转换。因此一切将继承层次对象作为catch语句的参数时，所有派生类对象的catch语句都应该放在继承类catch语句之前。

      如果catch语句的参数是一个类对象那么应该将他声明为引用或指针，这是因为：1.避免不必要的类复制和析构以提高效率；2.操作throw抛出的异常对象，以便重新抛出以后后续catch语句的处理；3.如果catch的参数是基类的引用或指针，当抛出的异常对象是派生类时，那么就能根据实际的异常对象来调用相关的虚拟函数。

四、异常规范

      使用一层规范时我们必须注意以下两点1.函数指针的异常规范必须比赋给他的函数的异常规范宽松或者相同；2.派生类虚拟函数的异常规范必须与基类虚拟函数的异常规范相同或者更加严格。

五、栈展开

      当抛出一个异常时，程序代码将首先在抛出异常的函数中查找能够处理该异常的catch语句，如果该函数定义中找不到能够处理该异常的catch语句或者该函数不在try块中时，程序代码将沿着函数调用链向上查找相应的catch语句。在这个过程中从异常抛出的函数到能够处理异常的catch语句所在的函数之间的函数都会被结束，所有的自动对象、类对象都会被释放，但是由于自由储存区上的对象不会被自动释放由此可能带来内存的泄漏，解决这个问题的方法有两种：1.用类来封装资源的分配和释放就象auto_ptr模板一样；2.在相应的函数中包含相应的catch语句用于释放资源，之后重新抛出异常。

C++异常处理

@H_450_44@ 2007年03月14日 星期三 23:15

1.@R_450_5179@  异常处理的使用 首先说明，千万别对异常处理钻牛角尖，那样会死人的（当然是烦死的）！ 在C++编程处理中，我秉承这样一个思想，就是：能不用异常处理的就不用。因为造成的混乱实在是太——多了。如果能用其他方法捕捉到错误并处理的话，誓死不用异常处理！呵呵，或许有点偏激，但我认为，这不失为一个避免不必要的错误的一个好办法。当什么分配内存失败，打开文件失败之类的通常错误，我们只需用assert，abort之类的函数就解决问题了。也就是说，假如有足够的信息去处理一个错误，那么这个错误就不是异常。 @R_450_5179@ 当然了，异常处理的存在也有它本身的意义和作用。不是你说不用就不用的，有些地方还非得用不可！ @R_450_5179@ 比如说，在当前上下文环境中，无法捕捉或确定的错误类型，我们就得用一个异常抛出到更大的上下文环境当中去。还有，异常处理的使用呢，可以使出错处理程序与“通常”代码分离开来，使代码更简洁更灵活。另外就是程序必不可少的健壮性了，异常处理往往在其中扮演着重要的角色。 @R_450_5179@ OK，下面阐述一下。 2.@R_450_5179@  抛出异常 关——键字（周星驰的语气）：throw 例——句：throw ExceptionClass(“oh,shit! it’s a exception!L “); 例句中，ExceptionClass是一个类，它的构造函数以一个字符串做为参数，用来说明异常。也就是说，在throw的时候，C++的编译器先构造一个ExceptionClass的对象，让它作为throw的返回值，抛——出去。同时，程序返回，调用析构。看下面这个程序： #include <iostream.h> class ExceptionClass{ @R_450_5179@ char* name; public: @R_450_5179@ ExceptionClass(char* name="default name")@R_450_5179@ { @R_450_5179@@R_450_5179@ cout<<"Construct "<<name<<endl; @R_450_5179@@R_450_5179@ this->name=name; @R_450_5179@ } @R_450_5179@ ~ExceptionClass()@R_450_5179@ { @R_450_5179@@R_450_5179@ cout<<"Destruct "<<name<<endl; @R_450_5179@ } @R_450_5179@ void myThrow(){ @R_450_5179@ throw ExceptionClass("o,my god"); }@R_450_5179@ }; void main(){ @R_450_5179@ ExceptionClass e("haha"); @R_450_5179@ try      { @R_450_5179@@R_450_5179@ e.myThrow(); @R_450_5179@ }@R_450_5179@ catch(...)     { @R_450_5179@ } } 大家看看结果就知道了，throw后，调用当前类的析构，整个结束了这个类的历史使命。唉~~ 3.@R_450_5179@  异常规格说明 如果我们调用别人的函数，里面有异常抛出，我用去查看它的源代码去看看都有什么异常抛出吗？可以，但是太——烦躁。比较好的解决办法，是编写带有异常抛出的函数时，采用异常规格说明，使我们看到函数声明就知道有哪些异常出现。 异常规格说明大体上为以下格式： void ExceptionFunction(argument…) throw(ExceptionClass1,ExceptionClass2,….) 对了，所有异常类都在函数末尾的throw()的括号中得以说明了，这样，对于函数调用者来说，是一清二楚了！ 注意下面一种形式： void ExceptionFunction(argument…) throw() 表明没有任何异常抛出。 而正常的void ExceptionFunction(argument…)则表示：可能抛出任何一种异常，当然就，也可能没有异常，意义是最广泛的哦。 4.@R_450_5179@  构造和析构中的异常抛出 55555，到了应该注意的地方了。 @R_450_5179@ 先看个程序，假如我在构造函数的地方抛出异常，这个类的析构会被调用吗？可如果不调用，那类里的东西岂不是不能被释放了？？ @R_450_5179@ 程序： #include <iostream.h> #include <stdlib.h> class ExceptionClass1{ @R_450_5179@ char* s; public: @R_450_5179@ ExceptionClass1(){ @R_450_5179@@R_450_5179@ cout<<"ExceptionClass1()"<<endl; @R_450_5179@@R_450_5179@ s=new char[4]; @R_450_5179@@R_450_5179@ cout<<"throw a exception"<<endl; @R_450_5179@@R_450_5179@ throw 18; @R_450_5179@ } @R_450_5179@ ~ExceptionClass1(){ @R_450_5179@@R_450_5179@ cout<<"~ExceptionClass1()"<<endl; @R_450_5179@@R_450_5179@ delete[] s; @R_450_5179@ } }; void main(){ @R_450_5179@ try{ @R_450_5179@@R_450_5179@ ExceptionClass1 e; @R_450_5179@ }catch(...) @R_450_5179@ {} } 结果为： ExceptionClass1() throw a exception 没了，没了，到此为止了！可是，可是，在这两句输出之间，我们已经给S分配了内存，哪里去了？内存释放了吗？没有，没有，因为它是在析构函数中释放的，哇！问题大了去了。怎么办？怎么办？ 为了避免这种情况，应避免对象通过本身的构造函数涉及到异常抛出。即：既不在构造函数中出现异常抛出，也不应在构造函数调用的一切东西中出现异常抛出。否则，只有完蛋。 那么，在析构函数中的情况呢？我们已经知道，异常抛出之后，就要调用本身的析构函数，如果这析构函数中还有异常抛出的话，则已存在的异常尚未被捕获，会导致异常捕捉不到哩。 完，也就是说，我们不要在构造函数和析构函数中存在异常抛出。 5.@R_450_5179@  异常捕获 上边的程序不知道大家看懂了没，异常捕获已经在上面出现了也。 没错，就是try{…}catch(…){…}这样的结构！ Try后面的花括号中，就是有可能涉及到异常的各种声明啊调用啊之类的，如果有异常抛出，就会被异常处理器截获捕捉到，转给catch处理。先把异常的类和catch后面小括号中的类进行比较，如果一致，就转到后面的花括号中进行处理。 例如抛出异常是这么写的： void f(){throw ExceptionClass(“ya,J”);} 假设类ExceptionClass有个成员函数function()在有异常时进行处理或相应的消息显示（只是做个例子哦，别挑我的刺儿）。 那么，我可以这么捕捉: try{f()}catch(ExceptionClass E){e.function()}; 当然，象在上面程序中出现的一样，我可以在catch后用三个点来代表所有异常。如try{f()}catch(…){}。这样就截断了所有出现的异常。有助于把所有没出现处理的异常屏蔽掉（我是这么认为的J）。 异常捕获之后，我可以再次抛出，就用一个不带任何参数的throw语句就可以了，例如：try(f())catch(…){throw}