CLR内部异常(下)
作者:互联网
直接使用SEH
有些情况里直接使用SEH会更合适一些。特别是,如果需要在第一次遍历(first pass - SEH异常处理流程里的第一遍处理)时需要执行某些操作时,也就是在堆栈向上展开之前,SEH是唯一的选项。一个SEH里的 __try/__except 过滤代码除了决定是否要处理某个异常以外,还能执行任何操作。调试器通知(Debugger notification)就是在第一次遍历时需要考虑的领域。
过滤代码的编写需要极其小心。一般来讲,过滤代码需要考虑到任何随机,而且很可能不一致的状态。因为过滤代码在第一次遍历时执行,而析构函数(dtors)在第二次遍历时执行,holders还没有执行,而且也没有恢复它们的状态。
PAL_TRY / PAL_EXCEPT, PAL_EXCEPT_FILTER, PAL_FINALLY / PAL_ENDTRY
如果需要过滤代码,PAL_TRY家族代码是CLR里可移植的写法。因为过滤代码直接使用SEH,它不能在一个函数里与C++异常处理共存,因此在函数里不能使用holders。
再次强调,这种情况很少见。
__try / __except, __finally
在CLR里没有充足理由来直接使用它们。
异常和GC模式
使用COMPlusThrowXXX()抛出异常不会影响GC模式,而且在所有模式里都是安全的。当异常将堆栈展开到EX_CATCH,在栈上的所有holders都会销毁,释放它们的资源和重置它们的状态。当在EX_CATCH里恢复执行时,被holder保护的状态会恢复到EX_TRY时的状态。
转换
在托管代码,CLR,COM服务器和其它原生代码之间,有很多如调用规范(calling conventions),内存管理和异常处理机制之间的转换。关于异常,对CLR开发者来说是幸运的,大部分转换要么完全在CLR之外,或者就是被自动处理了。CLR开发人员日常需要考虑的就是三种转换。其它的都是高端话题。
托管代码进入CLR
由“fcall”、"jit helper"等触发。典型路径是CLR通过一个托管异常向托管代码报告错误。因此,如果是一个fcall函数直接或间接抛出一个托管异常,那没什么问题。一般的CLR托管异常实现会“做正确的事”而且会去找一个适合的托管异常处理代码。
从另一面来说,如果fcall函数也可以包含抛出CLR内部异常的代码(一个C++异常),这个异常不能泄漏到托管代码那边。为了处理这种情况,CLR提供了UnwindAndContinueHandler (UACH),它是捕捉C++异常并转换成托管异常并抛出的一系列代码。
任何从托管代码端调用的CLR函数都有可能抛出C++异常,必须将抛出异常的代码封装在INSTALL_UNWIND_AND_CONTINUE_HANDLER / UNINSTALL_UNWIND_AND_CONTINUE_HANDLER里。安装一个HELPER_METHOD_FRAME会自动安装UACH。安装UACH的性能代价很大,因此不能随处使用。一种技术是,在执行关键代码的时候不要使用UACH,但是在抛出异常之前安装一个UACH。
当一个C++异常被抛出时,而少了一个UACH,典型错误就是一个在CPFH_RealFirstPassHandler里“GC_TRIGGERS在一个GC_NOTRIGGER区域里被调用”的合约违规(Contract Violation)。要修复这些错误,留意托管代码到CLR的切换,并检查INSTALL_UNWIND_AND_CONTINUE_HANDLER或HELPER_METHOD_FRAME_BEGIN_XXX。
CLR代码到托管代码
从CLR切换到托管代码是跟平台很相关的。在32位Windows平台,CLR托管异常代码要求在进入托管代码之前已经安装了“COMPlusFrameHandler”。这些切换被一些专用的辅助函数处理,它们来执行恰当的异常处理。一般对托管代码的调用很少用其它方法。如果没有COMPlusFrameHander,最可能的情况就是托管代码端的异常处理代码没有被执行,finally块和catch块都不会被执行。
CLR代码切换到外部原生代码
从CLR调用其它原生代码(操作系统、CRT和其它DLL)的过程要格外注意。这是因为外部代码可能会触发一个异常。由于EX_TRY宏的实现方式,这是一个问题,特别是它们将一个非异常错误翻译或者封装异常的方式。对于C++异常,只能通过放弃捕捉到的异常的所有信息,是可以捕捉任意或者所有异常(通过"catch(...)")。捕捉到一个异常后*,这个宏有异常对象可检查,但如果捕捉到其它东西,那就没什么可检查的了,宏只能猜异常是什么。如果异常是从CLR外部来的,那宏总是会猜错。
目前的解决方案是将对外部代码的调用封装到一个“callout filter”。这个过滤代码会捕捉外部异常,并将它翻译成一个CLR内部异常:SEHException。这个过滤代码是预定义的,而且用起来也很简单。然而,使用过滤代码就意味着使用SEH,因此在同一个函数里不能使用C++异常。在使用C++异常的函数里加上“callout filter”要求将它分成两个函数。
要使用callout filter,这样的代码:
length = SysStringLen(pBSTR);
要写成:
BOOL OneShot = TRUE; PAL_TRY { length = SysStringLen(pBSTR); } PAL_EXCEPT_FILTER(CallOutFilter, &OneShot) { _ASSERTE(!"CallOutFilter returned EXECUTE_HANDLER."); } PAL_ENDTRY;
如果函数抛出了一个异常,而没有callout filter的话,后果就是CLR会报告一个错误的异常。而且错误报告的异常类型也不是确定的;如果系统里已经有托管异常,那么就会报告成这个托管异常。如果没有异常抛出,那么就会报告成一个内存不足异常(OOM)。在调试版里,如果缺失callout filter,会触发一个断言。断言消息会包含“The runtime may have lost track of the type of an exception(运行时可能无法确定异常的类型)”。
其它
在EX_TRY里实际上包含很多宏,这些宏永远不能在宏的实现以外使用。
BEGIN_EXCEPTION_GLUE / END_EXCEPTION_GLUE需要特别提一下。它们本来是用做切换宏的,在VS 2008里应该被换成更恰当的宏。当然,它们现在工作的很好,因此也不用被换掉。理想情况下,是在一个“清理”里程碑里,将这些实例都换掉,然后删掉这些宏。CLR开发人员如果要用它们的话,应该使用EX_TRY/EX_CATCH/EX_CATCH_END或 EX_CATCH_HRESULT。
作者:懿民链接:https://www.jianshu.com/p/efb65766f9fe
来源:简书
标签:内部,异常,代码,托管,EX,PAL,CLR 来源: https://www.cnblogs.com/yilang/p/11833540.html