C++和异常
再回头来说我们在第一节里说到的 EXCEPTION_REGISTRATION结构，这个结构是用来注册操作系统的异常回调函数的，当异常发生时，该函数将被调用。
VC++扩展了异常回调函数得语法，增加了两个新的参数:
struct EXCEPTION_REGISTRATION
{
EXCEPTION_REGISTRATION *prev;
DWORD handler;
int id;
DWORD ebp;
};
VC ++里，除了一些例外，在每个函数的头部生成EXCEPTION_REGISTRATION结构的局部变量(作者注：编译器可能在一个函数里根本不生成任何异常相关的代码，如果函数里没有try或者所有的局部对象都没有可供调用的析构函数(译注：当异常产生时，要把堆栈顶到catch到异常那点之间的局部变量都释放掉，这是异常处理一个重要责任。如果这些局部变量都不需要去特别释放，比如int变量或简单结构变量，只要把堆栈指针指过来就可以了，异常处理在这一段里就是没有必要的，因此编译器识别了这样的情况，作个一定的优化))。上面结构的ebp和前面说的堆栈帧里的ebp指针是重叠在一起的(译注：请参看C++编译器怎么实现异常处理2)，函数在开始时把这个结构创建在它的堆栈上，同时把这个结构注册到操作系统(译注：就是把FS:[0]的位置改成这个结构的指针）；在函数的结尾恢复调用者在系统注册的EXCEPTION_REGISTRATION结构(译注：就是把FS:[0]改成结构里的prev)，我将在下一节讨论EXCEPTION_REGISTRATION结构里的id域的重要性。
当VC++编译一个函数，它生成函数的两套数据：
a) 异常的回调函数
b) 一个包含重要信息的数据结构，这些重要信息比如，各个catch块，它们的地址，关心的异常的种类等等，我将在下一节更多的谈论它
图 4 显示了如果考虑异常处理，程序运行时堆栈的情况。Widget的异常回调是在异常链的头部(异常链的头部就是FS:[0]指向的内容)，FS:[0]的内容就是在Widget头部定义的EXCEPTION_REGISTRATION结构的指针。当异常产生时，异常处理把Widget的函数信息结构的地址(就是EXCEPTION_REGISTRATION的指针)传递给__CxxFrameHandler函数，__CxxFrameHandler函数检查这个数据结构，察看函数里是否有catch块对当前的异常感兴趣，如果没有找到，函数返回ExceptionContinueSearch给操作系统，操作系统获得异常处理链里的下一个节点，再调用这个节点的异常处理函数（这个节点应该是在本函数的调用者定义的)
这个动作一直持续到异常处理找到一个对这个异常感兴趣的catch块，找到了匹配的catch块以后，程序不再返回到操作系统。但是在它调用catch块前(在函数信息结构里有这个异常回调函数的指针，看图4),异常处理必须执行堆栈释放：清除这个函数之前的所有函数的堆栈帧。清除堆栈帧的动作有点复杂，异常处理必须找到所有在异常产生时还没有结束的函数，找到每个函数所有的局部变量，调用每个变量的析构函数。我将在以后的章节里更详细的讨论这点。
异常处理是这样一个任务，当异常处理时清除异常处理所在的函数帧。这个操作是从FS:[0]指向的位置，也就是异常处理链头开始的， 然后沿着链一个节点一个节点的通知它所在的堆栈将要被回收，收到通知的节点，调用所在帧的所有局部对象的析构然后返回，这个过程一直延续到抛出的异常被捕获到。
因为catch块也是某个函数的一部分，所以它也用了所在函数的函数帧来保存数据。因此异常处理的一个catch块进入的时候会激活所在函数的那一帧(译注：就是会把ebp改到那个函数去，而esp是不动的，简单的说，在catch函数块里执行的时候，ebp是指向所在函数的帧顶，而esp可能在非常远的堆栈顶端）。同时，每个能能捕获异常的catch块(就是异常种类和catch块要捕获的异常种类一致)实际上只有一个参数，就是这个异常对象的拷贝或者是异常对象的引用拷贝。catch块知道怎么从函数信息结构中拷贝这个异常对象，编译器已经产生了足够多的信息（译注：就是根据传入的id，来判断怎么复制异常)。
当拷贝了异常对象同时激活了函数帧以后，异常处理就开始调用catch块，catch块的返回告诉异常处理在try-catch后面跟着执行(译注：当然也可以在catch块里接着throw)。注意，在这一时刻，即使堆栈恢复已经存在，而且函数帧都已经清理，但是这些地址仍然在堆栈上存在(译注：就是说在进入catch块函数时，仍然是用程序的堆栈，不过多压了好多东西进去，而在栈顶之前的一些东西都已经被清理了，但是它们仍然在堆栈上占据着空间，这个时间是检查错误来源的好时机，这也是我研究异常处理详细机制的目的)，这是因为异常处理仍然像其他函数一样的执行，它也使用程序堆栈来存放它的局部变量，cantch块存放局部变量的帧在异常产生时调用的最后一个函数的堆栈帧的上边(地址更低),当catch块返回时，需要删除这个异常对象的拷贝(译注：如果异常对象是在栈里，自动就删除了，如果是在堆了，需要用delete或者free明确删除)。在catch块的结尾，异常处理回收了包括自己的帧在内的所有已经清理的堆栈帧，实际上就是把esp指向当前函数帧的结尾(译注：前面说过在catch块里，ebp是catch所在函数的ebp比如是0x12ff58，而esp在很远的地方比如0x12f9bc，而实际上,esp到ebp之间的大部分东西都已经被删除了，现在把esp改回来，回到函数正常运行的状态，比如0x12ff80,0x12ff58-0x12ff80实际上是拥有catch块的那个函数的堆栈帧的范围)，完成这点以后，跳到try-catch块的下一条语句继续执行。但是catch块是怎么知道函数堆栈帧的尾在哪里的?这本来是没有办法知道的，这就是为什么编译器要在函数的堆栈帧的开头保存一个esp的原因。参看图4，堆栈帧指针EBP减去16就是esp所在的位置。
catch块自己可能会产生一个新的异常或者把当前异常重新抛出。异常不得不监视这种情况然后采取适当的操作。如果异常处理抛出一个新的异常，前一个异常就被删除。如果catch块决定再次抛出捕获的异常，前一个异常就被往后传递。
有一个需要注意的地方：因为每个线程都有自己的堆栈，所以都有它自己的一套异常处理链(由FS:[0]处指向的EXCEPTION_REGISTRATION 结构开始)
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在哪里？我将在下面回答这个问题。
上一页 1 2 3 4 下一页 |
安全中国首页 > 文章中心 > 编释语言