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

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块