CSDN博客

img ancienttale

C++编译器怎么实现异常处理4

发表于2002/11/21 10:06:00  1019人阅读

C++和异常2

 5 显示了函数信息(funinfo)结构的内容。请注意结构使用的名字可能和VC++编译器使用的实际名字不一样,而且我在图中只显示了有关的成员,结构中的unwind table成员我将在下一节讲到。

当异常产生时,异常处理不得不寻找函数中的catch块,首先它要知道函数里这个产生异常的语句是不是被一个try块所包含。如果函数根本就没有try块,异常处理直接就从函数里返回,否则,异常处理就从所有的try块里找出那个包含了这条语句的块。

首先 ,让我们来看看怎么来找这个关联的try块。在编译的时候,编译器赋给每个try块一个起始ID和一个结束ID,通过funcinfo结构,很容易找到这些ID。参看图5。编译器为函数里的每一个try块生成tryblock数据结构。

在以前的章节里,我已经说过了VC++扩展的EXCEPTION_REGISTRATION结构,这个结构里就有一个成员叫ID。这个结构是放在函数帧上的,参看图四。当异常产生的时候,异常处理从堆栈里获得这个结构里的ID成员,然后检测这个ID是不是等于try块的两个ID之一,或者值的范围在起始和结束ID之间。如果上述条件满足,那么产生异常的语句就是在这个try块里的,如果不是,异常处理就查找tryblocktable里的下一个try块。

谁在堆栈里写下这些值?应该把这个值赋成多少?编译器在函数的不同位置填写恰当的语句来更新当前帧的ID,通过这样的手段来反映当前的运行状态(译注:

比如,一段代码:

BOOL E1(FARPROC p)

{

try{ return (*p)(); }

catch(...) { printf("exception/r/n"); return FALSE; }

}

编译出来时这样的

var_10 = dword ptr -10h                   ;数据定义

var_C = dword ptr -0Ch                   ;数据定义

var_4 = dword ptr -4                        ;数据定义

push ebp               ;caller's ebp

mov ebp, esp             

push 0FFFFFFFFh           ;这就是id

push offset loc_401320    ;handle

mov eax, large fs:0      

push eax                  ;prev,堆栈里这四项组成了结构EXCEPTION_REGISTRATION

mov large fs:0, esp       ;然后将现在的EXCEPTION_REGISTRATION注册到fs:0上

push ecx

push ebx

push esi

push edi

mov [ebp+var_4], 0        ;这是把id从 0xffffffff变成0,这就是作者说的函数中恰当的位置

mov [ebp+var_10], esp     ;保留esp,见图四

call [ebp+arg_0]          ;调用函数

mov ecx, [ebp+var_C]     

mov large fs:0, ecx       ;恢复fs:0的值为prev,同时调用函数(*p)()的返回值是放在EAX中的,所以用的是ECX寄存器

pop edi

pop esi

pop ebx

mov esp, ebp

pop ebp                    ;恢复EBP

retn

)

例如:编译器会在try函数块进入的地方添加一条语句,把try函数块的起始ID写到函数的堆栈帧里。

当异常处理处理异常时找到了一个try函数块包含产生异常的语句,它能通过trycatch表检查这个try函数块是否有catch块能捕获这个产生的异常。请注意在嵌套的try函数块里,内层的try函数块产生的异常也在外层的try函数块的范围里。这样的情况下,异常处理先找内层的catch块,如果没有找到,才去找外层的try函数块。在生成tryblock表时,VC++把内层的tryblock结构放在外层的tryblock之前。

异常处理怎么知道(从catch块的结构中)一个catch块能不能捕获当前的异常呢?它是通过比较catch块的参数,那个异常对象的种类来做到这点的。

catch块能捕获的异常H和E是完全相同的类型,产生的异常就会被捕获。因此,异常处理不得不动态比较参数的类型。但是,一般来说,C或者是类似C的语言并不能很容易的在运行时决定参数的类型(译注:C就和汇编差不多,看着就知道长度,谁知道在源码里它是什么类型)。为此,定义个一个叫type_info的类,这个定义写在标准头文件<typeinfo> 里,用来描述变量运行时的类型。catchblock结构的第二个成员(图5)就是一个指向type_info结构的指针,代表了catch块参数的运行时的类型。type_info类重载了==操作符,用来判断两个类型是不是完全相同的类型。因此,所有的异常处理都要做这个比较(调用==操作符重载函数)来确认catchblock参数的type_info和产生的异常的type_info是否相等,从而判断当前的catch块能不能捕获当前异常。

异常处理从funcinfo结构里知道了catchblock的参数,但是怎么知道当前异常的type_info呢,当编译器遇到这样的语句

throw E();

它为这个抛出的异常创建一个excpt_info结构,参看图6。请注意名字可能和VC++编译器使用的有所不同,而且我只列出了有关的项。如图所示,异常的type_info可以通过excpt_info结构来访问。有些时候,异常处理要销毁异常(当catch块完成),也可能需要拷贝异常(在调用catch块之前),为了帮助异常处理完成这些任务,编译器产生异常的析构函数,拷贝构造函数和取异常对象的大小的函数(通过excpt_info结构)

 

如果catch块的参数是一个基类,产生的异常是它的派生类,异常处理仍然应该在异常产生时调用这个catch块。然而,比较这两个种类(基类和派生类)将返回false,因为这两个类型本来不是同一种类型。不管是type_info类提供的成员函数还是操作符,都不能判断两个类一个是不是另一个的子类。但是,在这样的情况下,异常处理却确实能捕获到这样的异常。这是怎么做到的呢?实际上,编译器为这个异常产生了更多的信息。如果异常类是从别的类派生的,那么etypeinfo_table(在结构excpt_info结构里)包含了etype_info(扩展的type_info,我命名的)指针指向所有的父类,这样异常处理比较catch块的type_info和catch块参数的所有的type_info(自己和自己的所有基类的type_info)。只要有一个匹配成功,catch块就会被执行。

在我总结这一节之前,至少还有一个问题,就是异常处理是怎么知道当前产生的异常的excpt_info在哪里?我将在下面回答这个问题。

VC++把throw语句编译成和下面类似的语句:

//throw E(); //compiler generates excpt_info structure for E.
E e = E();  //create exception on the stack
_CxxThrowException(&e, E_EXCPT_INFO_ADDR);

_CxxThrowException 把控制权传递给操作系统(通过软件中断,参看函数RaiseException),同时传递两个参数。操作系统在准备调用异常回调函数时,把这两个函数打包到结构_EXCEPTION_RECORD里。接着操作系统找到FS:[0]处的异常处理链头的第一个EXCEPTION_REGISTRATION结构,调用结构里的handle。指向EXCEPTION_REGISTRATION 的指针也就是异常处理的第二个参数。再提一下,在VC++里每一个函数在自己的那一帧堆栈上创建它自己的EXCEPTION_REGISTRATION 结构,同时把这个结构注册到系统。第二个参数对异常处理很重要,通过它可以找到像ID这样的成员(没有ID就不能确定catch块)。这个参数也能使异常处理知道函数的堆栈帧(这对清除本帧变量很有用),同时也能往下找出更多的EXCEPTION_REGISTRATION节点(这对清除堆栈很有用)。第一个参数是一个指向_EXCEPTION_RECORD结构的指针,通过它异常处理能找到异常对象的指针和excpt_info结构。异常处理的返回值定义在EXCPT.H里

(译注:

typedef enum _EXCEPTION_DISPOSITION {

ExceptionContinueExecution,

 ExceptionContinueSearch,

ExceptionNestedException,

 ExceptionCollidedUnwind }

 EXCEPTION_DISPOSITION; )

EXCEPTION_DISPOSITION (*handler)(
    _EXCEPTION_RECORD *ExcRecord,
    void * EstablisherFrame, 
    _CONTEXT *ContextRecord,
    void * DispatcherContext);

你能忽略最后的两个参数。异常处理的返回值是一个枚举(EXCEPTION_DISPOSITION类型)。在前面我们已经说到,如果异常处理不能找到catch块,它就返回ExceptionContinueSearch给操作系统。其他的不太重要的信息在结构_EXCEPTION_RECORD里,这个结构定义在WINNT.H里:

struct _EXCEPTION_RECORD
{
    DWORD ExceptionCode;
    DWORD ExceptionFlags; 
    _EXCEPTION_RECORD *ExcRecord;
    PVOID   ExceptionAddress; 
    DWORD NumberParameters;
    DWORD ExceptionInformation[15]; 
} EXCEPTION_RECORD; 

ExceptionInformation数组的个数和入口的种类由ExceptionCode决定。如果ExceptionCode表示异常是个C++异常(ExceptionCode是0x06d7363,当通过throw来产生异常就会出现这样的情况),那么ExceptionInformation数组包含了指向异常对象和excpt_info结构的指针。而其他的异常,基本上都没有入口。其他的异常有除0,访问拒绝等,都能在WINNT.H里找到它们对应的值。

异常处理通过EXCEPTION_RECORD结构的ExceptionFlags成员来决定异常时采取什么动作。如果这个值是EH_UNWINDING (定义在except.inc里),提示异常处理清除堆栈正在进行,这时,异常处理应该清除了函数堆栈帧然后返回。清除函数帧包括这样的动作,找到所有的在异常发生时还没有释放的局部变量,然后调用它们的析构函数。这点下一节继续讨论。否则,异常处理不得不在函数里继续查找匹配的catch块,然后调用找到的catch块

阅读全文
0 0

相关文章推荐

img
取 消
img