C++处理异常技巧-try,catch,throw,finally

《C++处理异常技巧-try,catch,throw,finally》由会员分享，可在线阅读，更多相关《C++处理异常技巧-try,catch,throw,finally（98页珍藏版）》请在装配图网上搜索。

1、这两天要处理一个异常的问题，刚好查了些相关的资料。在网上看到了一个不错的贴 子，就转了过来，方便本人，以及来此旅游的朋友学习。源地址： nt.html?91983,1异常处理的基本思想是简化程序的错误代码，为程序键壮性提供一个标准检测机制。也 许我们已经使用过异常，但是你会是一种习惯吗，不要老是想着当我打开一个文 件的时候才用异常判断一下，我知道对你来说你喜欢用return value 或者是printerror message 来做，你想过这样做会导致Memory Leak，系统退出，代码重复 /难读，垃圾一堆 .吗？现在的软件已经是n*365*24小时的运行了，软件的健壮已经是一个很要考虑

2、的时候了。自序：对写程序来说异常真的是很重要，一个稳健的代码不是靠返回ErrorMessage/return Value来解决的，可是往往我们从C走过来，习惯了这样的方式。仅 以本文献给今天将要来临的流星雨把，还好我能在今天白天把这写完，否则会是 第4个通宵了；同时感谢Jeffrey大师，没有他的SEH理论这篇文章只能完成一半，而且所有SEH列子的构想都来自他的指导；另外要感谢 Scott Meyers 大师，我是 看他的书长大的；还要感谢Adamc / Darwin / Julian，当然还有 Nick的Coffee内容导读：（请打开文档结构图来读这篇文章。）本文包括2个大的异常实现概念：C

3、+的标准异常和 SHE异常。C+ 标准异常：也许我们了解过他，但你有考虑过，其实你根本不会使用，你不相 信，那我问你：垃圾回收在C+中怎么实现？其实不需要实现， C+已经有了，但是你不会用，那么从 开始看把。也许很高兴看到错误之 后的Heap/Stack中对象被释放，可是如果没有呢？有或者试想一下一个能解决的错误，需要我们把整个程序Kill掉吗？在C+标准异常中我向你推荐这几章： 以及一个深点的 SHE异常：我要问你你是一个 WIN32程序员吗？如果不是，那么也许你真的不需要看这 块内容了，SHE是Windows 的结构化异常，每一个 WIN32程序员都应该要掌 握它。SHE 功能强大，包括

4、Termination handling和 Exception handling两大部分，强有力的维护了代码的健壮，虽然要以部分系统性能做牺牲（其实可以避免）。在SHE中有大量的代码，已经在 Win平台上测试过 了。这里要提一下：在 _fin ally 处理中编译器参与了绝大多数的工作，而Exception 则是OS接管了几乎所有的工作，也许我没有提到的是：对_finally 来说当遇到ExitThread/ExitProcess/abort等函数时，fin ally 块不会被执行。另，我们的代码使用软件异常是比 return error message 好2*32的方法。另，使用析构函数防止

5、资源泄漏这个节点引用了 More effective C+ 的条款9 ,用2个列子，讲述了我们一般都会犯下的错误，往往这种错误是我们没有意识到的但确实是会给我们的软件带来致命的Leak/Crash ，但这是有解决的方法的，那就是使用灵巧指针llo如果对照 的37条条款，关于异常的高级使用，有以下内容是没有完成的：l使用构造函数防止资源Leak ( More effective C+ #10)l禁止异常信息传递到析构Function 夕卜(More effective C+ #11)l通过引用捕获异常(More effective C+ #13)I谨慎使用异常规格(More effective

6、C+ #14)l 了解异常处理造成的系统开销(More effective C+ #15)l 限制对象数量 (More effective C+ #26)l 灵巧指针(More effective C+ #28)声明：节点： 和 节点： 中 有大量的关于 More effective C+的条款，所以本文挡只用于自我阅读和内部交流，任何公开化和商业化，事先声明与本人无关。C+异常C+引入异常的原因C+ 新增的异常机制改变了某些事情，这些改变是彻底的，但这些改变也可能让我 们不舒服。例如使用未经处理的pointer 变的很危险，Memory/Resource Leak变的更有可能了(别说什么 M

7、emory 便宜了，那不是一个优秀的程序员说的话。)， 写出一个具有你希望的行为的构造函数和析构函数也变的困难(不可预测)，当然最危险的也许是我们写出的东东狗屁了，或者是速度变慢了。大 多数的程序员知道 Howto use exception来处理我们的代码，可是很多人并不是很重视异常的处理(国外的很多Code倒是处理的很好，Java的Exception 机制很不错)。异常处理机制是解决某些问题的上佳办法，但同时它也引入了许多隐藏的控制流程；有时候，要正确无误的使用它并不容易。在异常被throw后，没有一个方法能够做到使软件的行为具有可预测性和可靠性(这句话不是我说的，是 Jack Reeve

8、s 写的 Coping with Exception 和 Herb Sutter 写的Excepti on-Safe Generic Con tai ners中的。)一个没有按照异常安全设计的程序想Run正常，是做梦，别去想没有异常出现的可能，对C程序来说，使用Error Code 就可以了，为什么还要引入异常？因为异常不能被 忽略。如果一个函数通过设置一个状态变量或返回错误代码来表示一个异常状态，没 有办法保证函数调用者将一定检测变量或测试错误代码。结果程序会从它遇到的异常状态继续运行，异常没有被捕获，程序立即会终止执行。在 C程序中，我们可以用int setjmp( jmp_buf env

9、 );和voidIongjmp( jmp_buf env, int value );这2个函数来完成和异常处理相识的功能，但是MSDN中介绍了在C+中使用longjmp 来调整stack时不能够对局部的对象 调用析构函数，但是对C+程序来说，析构函数是重要的(我就一般都把对象的Delete 放在析构函数中)。所以我们需要一个方法：能够通知异常状态，又不能忽略这个通知，并且Searchi ng the stack以便找到异常代码时，还要确保局部对象的析构函数被Call 。而C+的异常处理刚好就是来解决这些问题的。有的地方只有用异常才能解决问题，比如说，在当前上下文环境中，无法捕捉或确 定的错误类

10、型，我们就得用一个异常抛出到更大的上下文环境当中去。还有，异常处 理的使用呢，可以使出错处理程序与通常I代码分离开来，使代码更简洁更灵活。另外就是程序必不可少的健壮性了，异常处理往往在其中扮演着重要的角色。C+使用throw 关键字来产生异常，try关键字用来检测的程序块，catch关键字用 来填写异常处理的代码。异常可以由一个确定类或派生类的对象产生。C+能释放堆栈，并可清除堆栈中所有的对象。C+的异常和pascal不同，是要程序员自己去实现的，编译器不会做过多的动作。throw异常类编程抛出异常用throw ,女口：throw Excepti on Class( my throw );例句

11、中，Exceptio nClass是一个类，它的构造函数以一个字符串做为参数。也就是说，在throw 的时候，C+的编译器先构造一个ExceptionClass的对象，让它作为throw 的值抛出去。同时，程序返回，调用析构。看下面这个程序：#in clude class Exceptio nClasschar* n ame;public:Excepti on Class(c onst char* n ame=default n ame)coutC on struct n amen ame=n ame;Excepti on Class()coutDestruct n amee ndl;void

12、 mythrow()throw Exceptio nClass(my throw); void mai n()Excepti on Class e(Test);trye.mythrow();catch(.)cout II *| endl;这是输出信息：Con struct TestCon struct my throwDestruct my throw*Destruct my throw(这里是异常处理空间中对异常类的拷贝的析构)Destruct Test不过一般来说我们可能更习惯于把会产生异常的语句和要throw的异常类分成不同的类来写，下面的代码可以是我们更愿意书写的：class Exce

13、ptio nClasspublic:Excepti on Class(c onst char* n ame=Excepti on Default Class) coutExcepti on Class Con struct Strin ge ndl;Excepti on Class()coutException Class Destruct Stringendl;void ReportError() coutExcepti on Class: This is Report Error Messagee ndl; ;class ArguClasschar* n ame;public:ArguCl

14、ass(char* n ame=default n ame)coutC on struct Strin g: n amen ame=n ame;ArguClass()coutDestruct Strin g: n amee ndl;void mythrow()void Exceptio nFun ctio n(argume nt)throw()throw Exceptio nClass(my throw);； _tmai n()ArguClass e(haha);try e.mythrow();catch(i nt)coutlf This is Message display scree n.

15、 This is a Error!e ndl;catch(Excepti on Class pTest)pTest.ReportError();catch(.) cout朱*w(Exceptio nClass1,ExceptionClass2,.)所有异常类都在函数末尾的throw()的括号中得以说明了，这样，对于函数调用者来说，是一清二楚的。注意下面一种形式: 表明没有任何异常抛出。而正常的void ExceptionFunction(argument)则表示：可能抛出任何一种异常，当然，也可能没有异常，意义是最广泛的。异常捕获之后，可以再次抛出，就用一个不带任何参数的throw 语句就可以

16、了。构造和析构中的异常抛出这是异常处理中最要注意的地方了先看个程序，假如我在构造函数的地方抛出异常，这个类的析构会被调用吗？可如果 不调用，那类里的东西岂不是不能被释放了？#in clude #in clude class Exceptio nClass1char* s;public:Exceptio nClass1()coutExcepti on Class1()e ndl;s=new char4;coutthrow a excepti onen dl;throw 18;Exceptio nClass1()coutExcepti on Class1()processAdopti on();d

17、elete pa; 这个函数循环遍历 dataSource 内的信息，处理它所遇到的每个项目。 唯一要记住的 一点是在每次循环结尾处删除 ps。这是必须的，因为每次调用 readALA都建立一个 堆对象。如果不删除对象，循环将产生资源泄漏。现在考虑一下，如果 pa-processAdoption抛出了一个异常，将会发生什么?者。转递中，processAdoptio ns函数中的调用 pa-processAdopti on语句后的所有语句都被跳过，这就是说pa没有被删除。结果，任何时候pa-processAdoptio n抛出一个异常都会导致processAdoptio ns内存泄漏。堵塞泄漏很

18、容易，void processAdopti on s(istream& dataSource)while (dataSource) ALA *pa = readALA(dataSource);try pa-processAdopti on();catch (.) /捕获所有异常delete pa;/避免内存泄漏/当异常抛出时throw;/传送异常给调用者delete pa;/避免资源泄漏/当没有异常抛出时但是你必须用try和catch对你的代码进行小改动。更重要的是你必须写双份清除 代码，一个为正常的运行准备，一个为异常发生时准备。在这种情况下，必须写两个delete代码。象其它重复代码一样，

19、这种代码写起来令人心烦又难于维护，而且 它看上去好像存在着问题。不论我们是让processAdoptio ns正常返回还是抛出异常，我们都需要删除 pa，所以为什么我们必须要在多个地方编写删除代码呢？我们可以把总被执行的清除代码放入processAdoptions函数内的局部对象的析构函数里，这样可以避免重复书写清除代码。因为当函数返回时局部对象总是被释放，无论函数是如何退出的。（仅有一种例外就是当你调用Iongjmp 时。Longjmp 的这个缺点是C+率先支持异常处理的主要原因）具体方法是用一个对象代替指针pa，这个对象的行为与指针相似。当pointer-like（类指针）对象被释放时，我

20、们能让它的析构函数调用delete。替代指针的对象被称为smart pointers（灵巧指针），下面有解释，你能使得pointer-like对象非常灵巧。在这里，我们用不着这么聪明的指针，我们只需要一个poi nter-lik对象，当它离开生存空间时知道删除它指向的对象。写出这样一个类并不困难，但是我们不需要自己去写。标准C+库函数包含一个类模板，叫做auto_ptr ，这正是我们想要的。每一个auto_ptr 类的 构造函数里，让一个指针指向一个堆对象（heap object ），并且在它的析构函数里删除这个对象。 下面所示的是auto_ptr类的一些重要的部分：templateclass

21、 auto_ptr public:/保存ptr，指向对象/删除ptr指向的对象/ raw ptr to objectauto_ptr(T *p = 0): ptr(p) auto_ptr() delete ptr; private:T *ptr;auto_ptr类的完整代码是非常有趣的，上述简化的代码实现不能在实际中应用。（我们至少必须加上拷贝构造函数，赋值operator以及下面将要讲到的poi nter-emulati ng函数），但是它背后所蕴含的原理应该是清楚的：用auto_ptr对象代替raw指针，你将不再为堆对象不能被删除而担心，即使在抛出异常时，对象也能被及时删除。（因为auto

22、_ptr的析构函数使用的是单对象形式的delete，所以auto_ptr 不能用于指向对象数组的指针。如果想让auto_ptr类似于一个数组模板，你必须自己写一个。在这种情况下，用vector代替array可能更好） auto_ptrtemplateclass auto_ptr public:typedef T eleme nt_type;explicit auto_ptr(T *p = 0) throw();auto_ptr(c onst auto_ptr& rhs) throw(); auto_ptr& operator=(auto_ptr& rhs) throw(); auto_ptr(

23、);T& operator*() const throw();T *operator-() const throw();T *get() const throw();T *release() const throw();；使用 auto_ptr对象代替 raw 指针，processAdoptions女口下所示：void processAdopti on s(istream& dataSource)while (dataSource) auto_ptr pa(readALA(dataSource);pa-processAdopti on();这个版本的processAdoptions在两个方面区

24、别于原来的processAdoptions函数。第一，pa被声明为一个 auto_ptr对象，而不是一个 raw ALA* 指针。第二，在循环的结尾没有 delete语句。其余部分都一样，因为除了析构的方式，auto_ptr 对象的行为就象一个普通的指针。是不是很容易。隐藏在auto_ptr后的思想是：用一个对象存储需要被自动释放的资源，然后依靠对象的析构函数来释放资源，这种思想不只是可以运用在指针上，还能用在其它资源的分配和释放上。想一下这样一个在GUI程序中的函数，它需要建立一个window 来显式一些信息：/这个函数会发生资源泄漏，如果一个异常抛出void display In fo(c

25、 onst In formatio n& info)WINDOW_HANDLE w(createWi ndow();在w对应的window中显式信息destroyWi ndow(w);很 多window 系统有 C like 接口，使用象like createWindow和destroyWindow函数来获取和释放 window 资源。如果在 w对应的 window 中显示信息时，一个异常被抛出，w所对应的window 将被丢失，就象其它动态分配的资源一样。解决方法与前面所述的一样，建立一个类，让它的构造函数与析构函数来获取和释放资源：file:/ 一个类，获取和释放一个 win dow 句柄

26、class Win dowHa ndle public:Win dowHa ndle(WINDOW_HANDLE han dle): w(ha ndle) Win dowHa ndle() destroyWi ndow(w); operator WINDOW_HANDLE() return w; / see belowprivate:WINDOW_HANDLE w;II下面的函数被声明为私有，防止建立多个WINDOW_HANDLE 拷贝file:/有关一个更灵活的方法的讨论请参见下面的灵巧指针Win dowHa ndle(co nst Win dowHa ndle &);Win dowHa n

27、dle & operator* onst Win dowHa ndle&);这看上去有些象auto_ptr ，只是赋值操作与拷贝构造被显式地禁止(参见 More effective C+ 条款27 )，有一个隐含的转换操作能把 WindowHandle 转换为WINDOW_HANDLE。这个能力对于使用WindowHandle对象非常重要，因为这意味着你能在任何地方象使用raw WINDOW_HANDLE 一样来使用WindowHandle。(参见 More effective C+ 条款5，了解为什么你应该谨慎使用隐式类型转换操作)通过给出的 WindowHandle类，我们能够重写 dis

28、playInfo函数，如下所示：/如果一个异常被抛出，这个函数能避免资源泄漏void display In fo(c onst In formatio n& info)Win dowHa ndle w(createWi ndow();在w对应的window中显式信息即使一个异常在 displaylnfo内被抛出，被createWindow 建立的window 也能被释放。资源应该被封装在一个对象里，遵循这个规则，你通常就能避免在存在异常环境里 发生资源泄漏。但是如果你正在分配资源时一个异常被抛出，会发生什么情况呢？例 如当你正处于resource-acquiri ng类的构造函数中。还有如果这

29、样的资源正在被释放时，一个异常被抛出，又会发生什么情况呢？构造函数和析构函数需要特殊的技术。你能在 More effective C+ 条款 10 和 More effective C+ 条款 11 中获取 有关的知识。抛出一个异常的行为个人认为接下来的这部分其实说的很经典，对我们理解异常行为/异常拷贝是很有帮助的。条款12 :理解抛出一个异常I与传递一个参数I或调用一个虚函数I间的差异从语法上看，在函数里声明参数与在catch子句中声明参数几乎没有什么差别:class Widget . ;/void f1(Widget w);void f2(Widget & w);void f3(co ns

30、t Widget& w);void f4(Widget *pw);void f5(co nst Widget *pw);catch (Widget w).catch (Widget& w).catch (const Widget & w).catch (Widget *pw) .catch (const Widget *pw) .file:/ 一个类，具体是什么类在这里并不重要/ 一些函数，其参数分别为/ Widget, Widget&,或/ Widget* 类型file:/ 一些catch 子句，用来file:/捕获异常，异常的类型为/ Widget, Widget&, 或/ Widget*

31、你因此可能会认为用 throw抛出一个异常到catch子句中与通过函数调用传递一个 参数两者基本相同。这里面确有一些相同点，但是他们也存在着巨大的差异。让我们先从相同点谈起。你传递函数参数与异常的途径可以是传值、传递引用或传 递指针，这是相同的。但是当你传递参数和异常时，系统所要完成的操作过程则是完 全不同的。产生这个差异的原因是：你调用函数时，程序的控制权最终还会返回到函 数的调用处，但是当你抛出一个异常时，控制权永远不会回到抛出异常的地方。有这样一个函数，参数类型是Widget，并抛出一个 Widget类型的异常:/ 一个函数，从流中读值到Widget中istream operator(i

32、strea m& s, Widget& w);void passA ndThrowWidget()Widget localWidget;cin localWidget;file:/ 传递 localWidget至U operatorthrow localWidget;/ 抛出 localWidget 异常当 传递localWidget至U函数operator里，不用进行拷贝操作，而是把operator 内的引用类型变量 w指向localWidget ,任何对w的操作实际上都施 加到localWidget上。这与抛出localWidget异常有很大不同。不论通过传值捕获异 常还是通过引用捕获(不

33、能通过指针捕获这个异常，因为类型不匹配)都将进行 lcalWidget的拷贝操作，也就说传递到 catch子句中的是 localWidget的拷贝。必须这么做，因为当localWidget离开了生存空间后，其析构函数将被调用。如果把localWidget 本身(而 不是它的拷贝)传递给 catch子句，这个子句接收到的只是 一个被析构了的 Widget , 一个Widget的尸体II。这是无法使用的。因此C+规范要求被做为异常抛出的对象必须被复制。即使被抛出的对象不会被释放，也会进行拷贝操作。例如如果 passA ndThrowWidget函数声明localWidget为静态变量(static

34、 ),void passA ndThrowWidget()file:/现在是静态变量(static );直存在至程序结束cin localWidget;throw localWidget;当抛出异常时仍将复制出file:/localWidget常，也不能在 catch 块中修改localWidget异常对象进行强制复制拷贝，差异：抛出异常运行速度比参数传递要慢。/象以前那样运行/ 仍将对 localWidget 进行拷贝操作的一个拷贝。这表示即使通过引用来捕获异;仅仅能修改 localWidget 的拷贝。对这个限制有助于我们理解参数传递与抛出异常的第二个static Widget local

35、Widget;有这样一个函数，参数类型是Widget，并抛出一个 Widget类型的异常:有这样一个函数，参数类型是Widget，并抛出一个 Widget类型的异常:usidc52010-09-19 00:08当异常对象被拷贝时，拷贝操作是由对象的 拷贝构造函数完成的。该拷贝 构造函数是对象的静态类型(static type )所对应类的拷贝构造函数，而这个事实影响到你如何在catch块中再抛出一个catch 块，乍一看好像一样：catch (Widget & w)/捕获Widget异常/throw;catch (Widget & w)/处理异常/重新抛出异常，让它继续传递/捕获Widget异

36、常/处理异常/传递被捕获异常的 拷贝throw w;这两个catch块的差别在于第一个catch块中重新抛出的是当前捕获的异 常，而第二个catch块中重新抛出的是当前捕获异常的一个新的拷贝 果忽略生成额外拷贝的系统开销，这两种方法还有差异么？ 当然有。第一个块中重新抛出的是当前异常(current exception 它是什么类型。特别是如果这个异常开始就是做为SpecialWidget出的，那么第一个块中传递出去的还是 静态类型(static type )是 Widget 。/),无论 类型抛SpecialWidget 异常，即使 w的 这是因为重新抛出异常时没有进行不是对象的动态类型(d

37、ynamic type)对应类的拷贝构造函数。比如以下这经过少许修改的passAndThrowWidget:class Widget . ;class SpecialWidget: public Widget . ;void passA ndThrowWidget()SpecialWidget localSpecialWidget;Widget& rw = localSpecialWidget;/ rw 引用 SpecialWidgetthrow rw;file:/ 它抛出一个类型为 Widget/的异常 这 里抛出的异常对象是 Widget，即使rw引用的是一个SpecialWidget 因

38、为 rw 的静态类型(static type )是 Widget，而不是 SpecialWidget 。 你的编译器根本没有主要到rw引用的是一个SpecialWidget 。编译器所 注意的是rw的静态类型(static type )。这种行为可能与你所期待的不 一样，但是这与在其他情况下C+中拷贝构造函数的行为是一致的。(不 过有一种技术可以让你根据对象的动态类型dynamic type进行拷贝，参见条款25 异常是其它对象的拷贝， 异常。比如下面这两个拷贝操作。第二个catch块重新抛出的是新异常，类型总是Widget ，因为w的静态类型(static type )是Widget。一般来

39、说，你应该用throw来重新抛出当前的异常，因为这样不会改变被传递出去的异常类型，而且 更有效率，因为不用生成一个新拷贝。(顺便说一句，异常生成的拷贝是一个临时对象。正如条款19解释的，),抛出的：/通过传值捕获异常/通过传递引用捕获异常file:/通过传递指向const的引用临时对象能让编译器优化它的生存期(optimize it out of existe nee 不过我想你的编译器很难这么做，因为程序中很少发生异常，所以编译器 厂商不会在这方面花大量的精力。) 让我们测试一下下面这三种用来捕获 Widget异常的catch子句，异常是 做为 passAndThrowWidgetp cat

40、ch (Widget w)./catch (Widget & w).catch (const Widget & w).file:/捕获异常我 们立刻注意到了传递参数与传递异常的另一个差异。一个被异常抛出的对象(刚才解释过，总是一个临时对象)可以通过普通的引用捕获；它不 需要通过指向 const对象的引用(reference-to-const)捕获。在函数调用中不允许转递一个临时对象到一个非const引用类型的参数里(参见条款19 )，但是在异常中却被允许。让我们先不管这个差异，回到异常对象拷贝的测试上来。我们知道当用传 值的方式传递函数的参数，我们制造了被传递对象的一个拷贝(参见Effecti

41、ve C+ 条款22 )，并把这个拷贝存储到函数的参数里。同样我 们通过传值的方式传递一个异常时，也是这么做的。当我们这样声明一个 catch子句时：catch (Widget w) ./ 通过传值捕获会建立两个被抛出对象的拷贝，一个是所有异常都必须建立的临时对象， 第二个是把临时对象拷贝进 w中。同样，当我们通过引用捕获异常时， catch (Widget& w) ./ 通过引用捕获catch (const Widget& w) .file:/ 也通过引用捕获这仍旧会建立一个被抛出对象的拷贝：拷贝是一个临时对象。相反当我们 通过引用传递函数参数时，没有进行对象拷贝。当抛出一个异常时，系统 构

42、造的(以后会析构掉)被抛出对象的拷贝数比以相同对象做为参数传递 给函数时构造的拷贝数要多一个。我 们还没有讨论通过指针抛出异常的情况，不过通过指针抛出异常与通过指针传递参数是相同的。不论哪种方法都是一个指针的拷贝被传递。你不 能认为抛出的指针是 一个指向局部对象的指针，因为当异常离开局部变量 的生存空间时，该局部变量已经被释放。Catch子句将获得一个指向已经不存在的对象的指针。这种行为在设计时应该予以避免。对象从函数的调用处传递到函数参数里与从异常抛出点传递到 catch子句 里所采用的方法不同，这只是参数传递与异常传递的区 别的一个方面，第 二个差异是在函数调用者或抛出异常者与被调用者或异

43、常捕获者之间的类型匹配的过程不同。比如在标准数学库(the sta ndard math library中sqrt函数：double sqrt(double);/ from or 我们能这样计算一个整数的平方根，如下所示：int i;double sqrtOfi = sqrt(i);毫无疑问，C+允许进行从int到double的隐式类型转换，所以在sqrt 的调用中，i被悄悄地转变为double类型，并且其返回值也是double 。(有关隐式类型转换的详细讨论参见条款5) 一般来说，catch子句匹配异常类型时不会进行这样的转换。见下面的代码：void f(i nt value)/ 如果 so

44、meFunction()返回 file:/真，抛出一个整形值try if (someF unction() throw value;/只处理double类型的异常catch (double d) 在try块中抛出的int异常不会被处理double异常的catch子句捕获。该 子句只能捕获真真正正为double类型的异常；不进行类型转换。因此如 果要想捕获int异常，必须使用带有int或int&参数的catch子句。不过在catch子句中进行异常匹配时可以进行两种类型转换。第一种是继 承类与基类间的转换。一个用来捕获基类的catch子句也可以处理派生类类型的异常。例如在标准C+库(STL )定义

45、的异常类层次中的诊断部 分(diagnostics portion)(参见 Effective C+ 条款 49)。捕获runtime_errors 异常的Catch子句可以捕获range_error 类型和 overflow_error 类型的异常，可以接收根类 exception 异常的catch子 句能捕获其任意派生类异常。)间的异常类型转换可以作用于这种派生类与基类(inheritanee based数值、引用以及指针上：/ can catch errors of type / run time_error,/ ran ge_error, or/ overflow_error/ can

46、 catch errors of type / run time_error*,/ ran ge_error*, or/ overflow error*catch (run time_error) .catch (run time_error&) .catch (const run time_error&) .catch (run time_error*) .catch (const run time_error*) .第二种是允许从一个类型化指针(typed poi nter)转变成无类型指针(un typed poi nter),所以带有con st void* 指针的catch子句能捕获

47、任何类型的指针类型异常：catch (const void*) .file:/捕获任何指针类型异常传递参数和传递异常间最后一点差别是catch子句匹配顺序总是取决于它们在程序中出现的顺序。因此一个派生类异常可能被处理其基类异常的 catch子句捕获，即使同时存在有能处理该派生类异常的 catch子句，与 相同的try块相对应。例如：catch (logic_error& ex) try II这个catch块将捕获/ 所有的 logic_errorII异常，包括它的派生类catch (invalid_argument& ex) II这个块永远不会被执行.file:II因为所有的/ inv ali

48、d_argume ntII异常卡E被上面的II catch 子句捕获。与 上面这种行为相反，当你调用一个虚拟函数时，被调用的函数位于与发 出函数调用的对象的动态类型(dyn amic type )最相近的类里。你可以 这样说虚拟函数采用最优适合法，而异常处理采用的是最先适合法。如果 一个处理派生类异常的catch子句位于处理基类异常 的catch子句前面, 编译器会发出警告。(因为这样的代码在C+里通常是不合法的。)不过 你最好做好预先防范：不要把处理基类异常的catch子句放在处理派生类 异常的catch子句的前面。象上面那个例子，应该这样去写：try catch (invalid_argu

49、ment& ex) II 处理 invalid_argument file:/ 异常catch (logic_error& ex) II 处理所有其它的.II logic_errors 异常综上所述，把一个对象传递给函数或一个对象调用虚拟函数与把一个对象 做为异常抛出，这之间有三个主要区别。第一、异常对象在传递时总被进 行拷贝；当通过传值 方式捕获时，异常对象被拷贝了两次。对象做为参数 传递给函数时不需要被拷贝。第二、对象做为异常被抛出与做为参数传递 给函数相比，前者类型转换比后者要少(前者只有两种转换形式)。最后一点，catch子句进行异常类型匹配的顺序是它们在源代码中出现的顺序， 第一个类

50、型匹配成功的catch将被用来执行。当一个对象调用一个虚拟函 数时，被选择的函数位于与对象类型匹配最佳的类里，即使该类不是在源 代码的最前头。灵巧指针第一次用到灵巧指针 是在写ADO代码的时候，用到com_ptr_t 灵巧指 针；但一直印象不是很深；其实灵巧指针的作用很大，对我们来说垃圾回 收，ATL等都会使用到它，在 More effective的条款后面特意增加这个节点，不仅是想介绍它在异常处理方面的作用，还希望对编写别的类型代 码的时候可以有所帮助。smart pointer(灵巧指针)其实并不是一个指针，其实是某种形式的类。不过它的特长就是模仿C/C+中的指针，所以就叫pointer 了。所以希 望大家一定要记住两点：smart poin ter是一个类而非指针，但特长是模仿指针。那怎么做到像指