不捕捉某一个异常
常常有这种情况,代码不需要捕捉异常,但需要执行一些清理或者修正操作。虽然不总是,支持物(holders)经常用在这种场景里。在支持物(holders)不适用的情况里,CLR提供了两个“finally”块的变种。
EX_TRY_FOR_FINALLY
当需要在代码退出时执行修正操作时,一个finally块就比较合适。在CLR里有一系列的宏来实现try/finally:
EX_TRY_FOR_FINALLY
// code
EX_FINALLY
// exit and/or backout code
EX_END_FINALLY
注意:EX_TRY_FOR_FINALLY是基于SEH(Windows操作系统异常处理机制),而不是C++的异常处理机制。C++编译器不允许在一个函数里混合使用SEH和C++异常处理机制。有自动析构函数的局部变量要求C++异常处理机制以执行其析构函数。因此,使用了EX_TRY_FOR_FINALLY宏的函数不能同时使用EX_TRY,也不能有使用了自动析构函数的局部变量。
EX_HOOK
经常有这种情况,只在某种异常抛出的时候需要执行修正代码。对这些情况,EX_HOOK跟EX_FINALLY很类似,但是“勾子(hook)”子句只在有异常的时候执行。异常会自动在退出“勾子”子句之前再次抛出。
EX_TRY
// code
EX_HOOK
// code to run when an exception escapes the “code” block.
EX_END_HOOK
这个结构比简单的EX_CATCH配上EX_RETHROW块更好一些,因为其可以捕捉堆栈溢出异常(并向上展开堆栈),并再次抛出一个新的堆栈溢出异常。
抛出异常
在CLR里抛出异常其实就是下面的函数调用:
COMPlusThrow ( < args > )
有很多重载函数,但思路基本上就是向COMPlusThrow传入某个异常作为参数。异常类型由Rexcep.h中的一系列宏生成,如kAmbiguousMatchException, kApplicationException等类型。(重载函数)的其他参数指定资源和替代性文字。可以参考报告了类似异常的代码来选择异常类型。
以下是一些预定义的异常变种:
COMPlusThrowOOM();
最终调用ThrowOutOfMemory()函数,其抛出C++的OOM(内存不足)异常。它抛出一个预先创建的异常,因为不能在内存不足的情况下再找出内存创建这个异常!
当获取这个异常对应的托管异常时,CLR首先会尝试分配一个新托管对象[1],如果失败的话,那么就返回一个预先分配的,全局共享的内存不足异常对象。
[1] 毕竟,如果申请分配2G大小的数组失败,申请一个小对象还是可以试试的。
COMPlusThrowHR(HRESULT 问题HR);
如果你有IErrorInfo的话,有很多重载可用。还有一些惊人复杂的代码来指出一个HRESULT值对应哪种异常:
COMPlusThrowWin32(); / COMPlusThrowWin32(hr);
基本上是从Win32错误返回值抛出异常:HRESULT_FROM_WIN32(GetLastError())
COMPlusThrowSO();
抛出一个堆栈溢出(SO)异常。注意这个不是一个硬性的堆栈溢出,只是在可能导致硬性堆栈溢出的时候抛出的异常。
跟内存不足异常(OOM)类似,其抛出一个预先分配的C++堆栈溢出异常。跟OOM不同,当获取托管异常对象时,CLR总是返回预先分配的,全局共享的堆栈溢出异常对象。
COMPlusThrowArgumentNull()
抛出“参数不能为空”异常的辅助函数。
COMPlusThrowArgumentOutOfRange()
如名所示。
COMPlusThrowArgumentException()
另一个无效参数相关的异常。
COMPlusThrowInvalidCastException(thFrom, thTo)
传入强制转换的源类型和目的类型,这个函数可以返回一个相当不错的异常消息。
EX_THROW
这个是非常底层的抛出异常的函数,普通代码基本不用。很多COMPlusThrowXXX函数在内部使用EX_THROW,跟其它特定的ThrowXXX函数类似。最好少用EX_THROW,尽量使用封装好的函数以隐藏异常机制的细节。当然,如果没有合适的Throw函数可用,使用EX_THROW是可以接受的。
这个宏接受两个参数,要抛出的异常类型(C++ Exception类的某些子类),和用括号括起来的传递给该类型异常的构造函数的参数列表。
网友评论