C編譯器如何實(shí)現(xiàn)異常處理

1、C 編譯器如何實(shí)現(xiàn)異常處理C+編譯器如何實(shí)現(xiàn)異常處理轉(zhuǎn)自：原文出處：How aC+compiler implements exception handling譯者注：本文在網(wǎng)上已經(jīng)有幾個(gè)譯本，但都不完整，所以我決定自己把它翻譯過來。雖然力求信、雅、達(dá)，但鑒于這是我的第一次翻譯經(jīng)歷，不足之處敬請(qǐng)諒解并指出。與傳統(tǒng)語言相比，C+的一項(xiàng)革命性創(chuàng)新就是它支持異常處理。傳統(tǒng)的錯(cuò)誤處理方式經(jīng)常滿足不了要求，而異常處理則是一個(gè)極好的替代解決方案。它將正常代碼和錯(cuò)誤處理代碼清晰的劃分開來，程序變得非常干凈并且容易維護(hù)。本文討論了編譯器如何實(shí)現(xiàn)異常處理。我將假定你已經(jīng)熟悉異常處理的語法和機(jī)制。本文還提供了一個(gè)用

2、于VC+的異常處理庫，要用庫中的處理程序替換掉VC+提供的那個(gè)，你只需要調(diào)用下面這個(gè)函數(shù)：install_my_handler()；之后，程序中的所有異常，從它們被拋出到堆棧展開(stack unwinding)，再到調(diào)用catch塊，最后到程序恢復(fù)正常運(yùn)行，都將由我的異常處理庫來管理。與其它C+特性一樣，C+標(biāo)準(zhǔn)并沒有規(guī)定編譯器應(yīng)該如何來實(shí)現(xiàn)異常處理。這意味著每一個(gè)編譯器的提供商都可以用它們認(rèn)為恰當(dāng)?shù)姆绞絹韺?shí)現(xiàn)它。下面我會(huì)描述一下VC+是怎么做的，但即使你使用其它的編譯器或操作系統(tǒng)，本文也應(yīng)該會(huì)是一篇很好的學(xué)習(xí)材料。VC+的實(shí)現(xiàn)方式是以windows系統(tǒng)的結(jié)構(gòu)化異常處理(SEH)為基礎(chǔ)的。結(jié)

3、構(gòu)化異常處理-概述在本文的討論中，我認(rèn)為異?；蛘呤潜幻鞔_的拋出的，或者是由于除零溢出、空指針訪問等引起的。當(dāng)它發(fā)生時(shí)會(huì)產(chǎn)生一個(gè)中斷，接下來控制權(quán)就會(huì)傳遞到操作系統(tǒng)的手中。操作系統(tǒng)將調(diào)用異常處理程序，檢查從異常發(fā)生位置開始的函數(shù)調(diào)用序列，進(jìn)行堆棧展開和控制權(quán)轉(zhuǎn)移。Windows定義了結(jié)構(gòu)EXCEPTION_REGISTRATION，使我們能夠向操作系統(tǒng)注冊(cè)自己的異常處理程序。struct EXCEPTION_REGISTRATION EXCEPTION_REGISTRATION*prev；DWORD handler；注冊(cè)時(shí)，只需要?jiǎng)?chuàng)建這樣一個(gè)結(jié)構(gòu)，然后把它的地址放到FS段偏移0的位置上去就行了。

4、下面這句匯編代碼演示了這一操作：mov FS：0,exc_regp prev字段用于建立一個(gè)EXCEPTION_REGISTRATION結(jié)構(gòu)的鏈表，每次注冊(cè)新的EXCEPTION_REGISTRATION時(shí)，我們都要把原來注冊(cè)的那個(gè)的地址存到prev中。那么，那個(gè)異?；卣{(diào)函數(shù)長什么樣呢?在excpt.h中，windows定義了它的原形：EXCEPTION_DISPOSITION(*handler)(_EXCEPTION_RECORD*ExcRecord,void*EstablisherFrame,_CONTEXT*ContextRecord,void*DispatcherContext)；不要

5、管它的參數(shù)和返回值，我們先來看一個(gè)簡單的例子。下面的程序注冊(cè)了一個(gè)異常處理程序，然后通過除以零產(chǎn)生了一個(gè)異常。異常處理程序捕獲了它，打印了一條消息就完事大吉并退出了。#include iostream#include windows.h using std：cout；using std：endl；struct EXCEPTION_REGISTRATION EXCEPTION_REGISTRATION*prev；DWORD handler；EXCEPTION_DISPOSITION myHandler(_EXCEPTION_RECORD*ExcRecord,void*EstablisherFra

6、me,_CONTEXT*ContextRecord,void*DispatcherContext)coutIn the exception handlerendl；coutJust ademo.exiting.endl；exit(0)；return ExceptionContinueExecution；/不會(huì)運(yùn)行到這int g_div=0；void bar()/初始化一個(gè)EXCEPTION_REGISTRATION結(jié)構(gòu)EXCEPTION_REGISTRATION reg,*preg=reg.handler=(DWORD)myHandler；/取得當(dāng)前異常處理鏈的頭DWORD prev；_asm

7、 mov EAX,FS：0mov prev,EAX reg.prev=(EXCEPTION_REGISTRATION*)prev；/注冊(cè)！_asm mov EAX,preg mov FS：0,EAX/產(chǎn)生一個(gè)異常int j=10/g_div；/異常，除零溢出int main()bar()；return 0；/*-輸出-In the exception handler Just ademo.exiting.-*/注意EXCEPTION_REGISTRATION必須定義在棧上，并且必須位于比上一個(gè)結(jié)點(diǎn)更低的內(nèi)存地址上，Windows對(duì)此有嚴(yán)格要求，達(dá)不到的話，它就會(huì)立刻終止進(jìn)程。函數(shù)和堆棧堆棧是用

8、來保存局部對(duì)象的連續(xù)內(nèi)存區(qū)。更明確的說，每個(gè)函數(shù)都有一個(gè)相關(guān)的棧楨(stack frame)來保存它所有的局部對(duì)象和表達(dá)式計(jì)算過程中用到的臨時(shí)對(duì)象，至少理論上是這樣的。但現(xiàn)實(shí)中，編譯器經(jīng)常會(huì)把一些對(duì)象放到寄存器中以便能以更快的速度訪問。堆棧是一個(gè)處理器(CPU)層次的概念，為了操縱它，處理器提供了一些專用的寄存器和指令。圖1是一個(gè)典型的堆棧，它示出了函數(shù)foo調(diào)用bar，bar又調(diào)用widget時(shí)的情景。請(qǐng)注意堆棧是向下增長的，這意味著新壓入的項(xiàng)的地址低于原有項(xiàng)的地址。通常編譯器使用EBP寄存器來指示當(dāng)前活動(dòng)的棧楨。本例中，CPU正在運(yùn)行widget，所以圖中的EBP指向了widget的棧楨。

9、編譯器在編譯時(shí)將所有局部對(duì)象解析成相對(duì)于棧楨指針(EBP)的固定偏移，函數(shù)則通過棧楨指針來間接訪問局部對(duì)象。舉個(gè)例子，典型的，widget訪問它的局部變量時(shí)就是通過訪問棧楨指針以下的、有著確定位置的幾個(gè)字節(jié)來實(shí)現(xiàn)的，比如說EBP-24。上圖中也畫出了ESP寄存器，它叫棧指針，指向棧的最后一項(xiàng)。在本例中，ESP指著widget的棧楨的末尾，這也是下一個(gè)棧楨(如果它被創(chuàng)建的話)的開始位置。處理器支持兩種類型的棧操作：壓棧(push)和彈棧(pop)。比如，pop EAX的作用是從ESP所指的位置讀出4字節(jié)放到EAX寄存器中，并把ESP加上(記住，棧是向下增長的)4(在32位處理器上)；類似的，pu

10、sh EBP的作用是把ESP減去4，然后將EBP的值放到ESP指向的位置中去。編譯器編譯一個(gè)函數(shù)時(shí)，會(huì)在它的開頭添加一些代碼來為其創(chuàng)建并初始化棧楨，這些代碼被稱為序言(prologue)；同樣，它也會(huì)在函數(shù)的結(jié)尾處放上代碼來清除棧楨，這些代碼叫做尾聲(epilogue)。一般情況下，序言是這樣的：Push EBP；把原來的棧楨指針保存到棧上Mov EBP,ESP；激活新的棧楨Sub ESP,10；減去一個(gè)數(shù)字，讓ESP指向棧楨的末尾第一條指令把原來的棧楨指針EBP保存到棧上；第二條指令通過讓EBP指向主調(diào)函數(shù)的EBP的保存位置來激活被調(diào)函數(shù)的棧楨；第三條指令把ESP減去了一個(gè)數(shù)字，這樣ESP就

11、指向了當(dāng)前棧楨的末尾，而這個(gè)數(shù)字是函數(shù)要用到的所有局部對(duì)象和臨時(shí)對(duì)象的大小。編譯時(shí)，編譯器知道函數(shù)的所有局部對(duì)象的類型和體積，所以，它能很容易的計(jì)算出棧楨的大小。尾聲所做的正好和序言相反，它必須把當(dāng)前棧楨從棧上清除掉：Mov ESP,EBP Pop EBP；激活主調(diào)函數(shù)的棧楨Ret；返回主調(diào)函數(shù)它讓ESP指向主調(diào)函數(shù)的棧楨指針的保存位置(也就是被調(diào)函數(shù)的棧楨指針指向的位置)，彈出EBP從而激活主調(diào)函數(shù)的棧楨，然后返回主調(diào)函數(shù)。一旦CPU遇到返回指令，它就要做以下兩件事：把返回地址從棧中彈出，然后跳轉(zhuǎn)到那個(gè)地址去。返回地址是主調(diào)函數(shù)執(zhí)行call指令調(diào)用被調(diào)函數(shù)時(shí)自動(dòng)壓棧的。Call指令執(zhí)行時(shí)，會(huì)

12、先把緊隨在它后面的那條指令的地址(被調(diào)函數(shù)的返回地址)壓入棧中，然后跳轉(zhuǎn)到被調(diào)函數(shù)的開始位置。圖2更詳細(xì)的描繪了運(yùn)行時(shí)的堆棧。如圖所示，主調(diào)函數(shù)把被調(diào)函數(shù)的參數(shù)也壓進(jìn)了堆棧，所以參數(shù)也是棧楨的一部分。函數(shù)返回后，主調(diào)函數(shù)需要移除這些參數(shù)，它通過把所有參數(shù)的總體積加到ESP上來達(dá)到目的，而這個(gè)體積可以在編譯時(shí)知道：Add ESP,args_size當(dāng)然，也可以把參數(shù)的總體積寫在被調(diào)函數(shù)的返回指令的后面，讓被調(diào)函數(shù)去移除參數(shù)，下面的指令就在返回主調(diào)函數(shù)前從棧中移去了24個(gè)字節(jié)：Ret 24取決于被調(diào)函數(shù)的調(diào)用約定(call convention)，這兩種方式每次只能用一個(gè)。你還要注意的是每個(gè)線程都

13、有自己獨(dú)立的堆棧。C+和異?；貞浺幌挛以诘谝还?jié)中介紹的EXCEPTION_REGISTRATION結(jié)構(gòu)，我們?cè)盟虿僮飨到y(tǒng)注冊(cè)了發(fā)生異常時(shí)要被調(diào)用的回調(diào)函數(shù)。VC+也是這么做的，不過它擴(kuò)展了這個(gè)結(jié)構(gòu)的語義，在它的后面添加了兩個(gè)新字段：struct EXCEPTION_REGISTRATION EXCEPTION_REGISTRATION*prev；DWORD handler；int id；DWORD ebp；VC+會(huì)為絕大部分函數(shù)添加一個(gè)EXCEPTION_REGISTRATION類型的局部變量，它的最后一個(gè)字段(ebp)與棧楨指針指向的位置重疊。函數(shù)的序言創(chuàng)建這個(gè)結(jié)構(gòu)并把它注冊(cè)給操作系統(tǒng)，

14、尾聲則恢復(fù)主調(diào)函數(shù)的EXCEPTION_REGISTRATION。id字段的意義我將在下一節(jié)介紹。VC+編譯函數(shù)時(shí)會(huì)為它生成兩部分?jǐn)?shù)據(jù)：a)異常回調(diào)函數(shù)b)一個(gè)包含函數(shù)重要信息的數(shù)據(jù)結(jié)構(gòu)，這些信息包括catch塊、這些塊的地址和這些塊所關(guān)心的異常的類型等等。我把這個(gè)結(jié)構(gòu)稱為funcinfo，有關(guān)它的詳細(xì)討論也在下一節(jié)。圖3是考慮了異常處理之后的運(yùn)行時(shí)堆棧。widget的異?；卣{(diào)函數(shù)位于由FS：0指向的異常處理鏈的開始位置(這是由widget的序言設(shè)置的)。異常處理程序把widget的funcinfo結(jié)構(gòu)的地址交給函數(shù)_CxxFrameHandler，_CxxFrameHandler會(huì)檢查這個(gè)結(jié)

15、構(gòu)看函數(shù)中有沒有catch塊對(duì)當(dāng)前的異常感興趣。如果沒有的話，它就返回ExceptionContinueSearch給操作系統(tǒng)，于是操作系統(tǒng)會(huì)從異常處理鏈表中取得下一個(gè)結(jié)點(diǎn)，并調(diào)用它的異常處理程序(也就是調(diào)用當(dāng)前函數(shù)的那個(gè)函數(shù)的異常處理程序)。這一過程將一直進(jìn)行下去-直到處理程序找到一個(gè)能處理當(dāng)前異常的catch塊為止，這時(shí)它就不再返回操作系統(tǒng)了。但是在調(diào)用catch塊之前(由于有funcinfo結(jié)構(gòu)，所以知道catch塊的入口，參見圖3)，必須進(jìn)行堆棧展開，也就是清理掉當(dāng)前函數(shù)的棧楨下面的所有其他的棧楨。這個(gè)操作稍微有點(diǎn)復(fù)雜，因?yàn)椋寒惓Ｌ幚沓绦虮仨氄业疆惓０l(fā)生時(shí)生存在這些棧楨上的所有局部對(duì)象

16、，并依次調(diào)用它們的析構(gòu)函數(shù)。后面我將對(duì)此進(jìn)行詳細(xì)介紹。異常處理程序把這項(xiàng)工作委托給了各個(gè)棧楨自己的異常處理程序。從FS：0指向的異常處理鏈的第一個(gè)結(jié)點(diǎn)開始，它依次調(diào)用每個(gè)結(jié)點(diǎn)的處理程序，告訴它堆棧正在展開。與之相呼應(yīng)，這些處理程序會(huì)調(diào)用每個(gè)局部對(duì)象的析構(gòu)函數(shù)，然后返回。此過程一直進(jìn)行到與異常處理程序自身相對(duì)應(yīng)的那個(gè)結(jié)點(diǎn)為止。由于catch塊是函數(shù)的一部分，所以它使用的也是函數(shù)的棧楨。因此，在調(diào)用catch塊之前，異常處理程序必須激活它所隸屬的函數(shù)的棧楨。其次，每個(gè)catch塊都只接受一個(gè)參數(shù)，其類型是它希望捕獲的異常的類型。異常處理程序必須把異常對(duì)象本身或者是異常對(duì)象的引用拷貝到catch塊的

17、棧楨上，編譯器在funcinfo中記錄了相關(guān)信息，處理程序根據(jù)這些信息就能知道到哪去拷貝異常對(duì)象了?？截愅戤惓２⒓せ顥E后，處理程序?qū)⒄{(diào)用catch塊。而catch塊將把控制權(quán)下一步要轉(zhuǎn)移到的地址返回來。請(qǐng)注意：雖然這時(shí)堆棧已經(jīng)展開，棧楨也都被清除了，但它們占據(jù)的內(nèi)存空間并沒有被覆蓋，所有的數(shù)據(jù)都還好好的待在棧上。這是因?yàn)楫惓Ｌ幚沓绦蛉栽趫?zhí)行，象其他函數(shù)一樣，它也需要棧來存放自己的局部對(duì)象，而其棧楨就位于發(fā)生異常的那個(gè)函數(shù)的棧楨的下面。catch塊返回以后，異常處理程序需要?dú)⒌舢惓?duì)象。此后，它讓ESP指向目標(biāo)函數(shù)(控制權(quán)要轉(zhuǎn)移到的那個(gè)函數(shù))的棧楨的末尾-這樣就把(包括它自己的在內(nèi)的)所有棧楨

18、都刪除了，然后再跳轉(zhuǎn)到catch塊返回的那個(gè)地址去，就勝利的完成整個(gè)異常處理任務(wù)了。但它怎么知道目標(biāo)函數(shù)的棧楨末尾在哪呢?事實(shí)上它沒法知道，所以編譯器把這個(gè)地址保存到了棧楨上(由前言來完成)，如圖3所示，棧楨指針EBP下面第16個(gè)字節(jié)就是。當(dāng)然，catch塊也可能拋出新異常，或者是將原來的異常重新拋出。處理程序必須對(duì)此有所準(zhǔn)備。如果是拋出新異常，它必須殺掉原來的那個(gè)；而如果是重新拋出原來的異常，它必須能繼續(xù)傳播(propagate)這個(gè)異常。這里我要特別強(qiáng)調(diào)一點(diǎn)：由于每個(gè)線程有自己獨(dú)立的堆棧，所以每個(gè)線程也都有自己獨(dú)立的、由FS：0指向的EXCEPTION_REGISTRATION鏈。C+和異

19、常-2圖4是funcinfo的布局，注意這里的字段名可能與VC+編譯器實(shí)際使用的不完全一致，而且我也只給出了和我們的討論相關(guān)的字段。堆棧展開表(unwind table)的結(jié)構(gòu)留到下節(jié)再討論。異常處理程序在函數(shù)中查找catch塊時(shí)，它首先要判斷異常發(fā)生的位置是否在當(dāng)前函數(shù)(發(fā)生異常的那個(gè)函數(shù))的一個(gè)try塊中。是則查找與此try塊相關(guān)的catch塊表，否則直接返回。先來看看它怎樣找try塊。編譯時(shí)，編譯器給每個(gè)try塊都分配了start id和end id。通過funcinfo結(jié)構(gòu)，異常處理程序可以訪問這兩個(gè)id，見圖4。編譯器為函數(shù)中的每個(gè)try塊都生成了相關(guān)的數(shù)據(jù)結(jié)構(gòu)。上一節(jié)中，我說過VC

20、+給EXCEPTION_REGISTRATION結(jié)構(gòu)加上了一個(gè)id字段。回憶一下圖3，這個(gè)結(jié)構(gòu)位于函數(shù)的棧楨上。異常發(fā)生時(shí)，處理程序讀出這個(gè)值，看它是否在try塊的兩個(gè)id確定的區(qū)間start id，end id中。是的話，異常就發(fā)生在這個(gè)try塊中；否則繼續(xù)查看try塊表中的下一個(gè)try塊。誰負(fù)責(zé)更新id的值，它的值又應(yīng)該是什么呢?原來，編譯器會(huì)在函數(shù)的多個(gè)位置安插代碼來更新id的值，以反應(yīng)程序的實(shí)時(shí)運(yùn)行狀態(tài)。比如說，編譯器會(huì)在進(jìn)入try塊的地方加上一條語句，把try塊的start id寫到棧楨上。找到try塊后，處理程序就遍歷與其關(guān)聯(lián)的catch塊表，看是否有對(duì)當(dāng)前異常感興趣的catch塊

21、。在try塊發(fā)生嵌套時(shí)，異常將既源于內(nèi)層try塊，也源于外層try塊。這種情況下，處理程序應(yīng)該按先內(nèi)后外的順序查找catch塊。但它其實(shí)沒必要關(guān)心這些，因?yàn)?，在try塊表中，VC+總是把內(nèi)層try塊放在外層try塊的前面。異常處理程序還有一個(gè)難題就是如何根據(jù)catch塊的相關(guān)數(shù)據(jù)結(jié)構(gòu)判斷這個(gè)catch塊是否愿意處理當(dāng)前異常。這是通過比較異常的類型和catch塊的參數(shù)的類型來完成的。例如下面這個(gè)程序：void foo()try throw E()；catch(H)/.如果H和E的類型完全相同的話，catch塊就要捕獲這個(gè)異常。這意味著處理程序必須在運(yùn)行時(shí)進(jìn)行類型比較，對(duì)C等語言來說，這是不可能的

22、,因?yàn)樗鼈儫o法在運(yùn)行時(shí)得到對(duì)象的類型。C+則不同，它有了運(yùn)行時(shí)類型識(shí)別(runtime type identification，RTTI)，并提供了運(yùn)行時(shí)類型比較的標(biāo)準(zhǔn)方法。C+在標(biāo)準(zhǔn)頭文件中定義了type_info類，它能在運(yùn)行時(shí)代表一個(gè)類型。catch塊數(shù)據(jù)結(jié)構(gòu)的第二個(gè)字段(ptype_info，見圖4)是一個(gè)指向type_info結(jié)構(gòu)的指針，它在運(yùn)行時(shí)就代表catch塊的參數(shù)類型。type_info也重載了=運(yùn)算符，能夠指出兩種類型是否完全相同。這樣，異常處理程序只要比較(調(diào)用=運(yùn)算符)catch塊參數(shù)的type_info(可以通過catch塊的相關(guān)數(shù)據(jù)結(jié)構(gòu)來訪問)和異常的type_in

23、fo是否相同，就能知道catch塊是不是愿意捕獲當(dāng)前異常了。catch塊的參數(shù)類型可以通過funcinfo結(jié)構(gòu)得到，但異常的type_info從哪來呢?當(dāng)編譯器碰到throw E()；這條語句時(shí)，它會(huì)為異常生成一個(gè)excpt_info結(jié)構(gòu)，如圖5所示。還是要提醒你注意這里用的名字可能與VC+使用的不一致，而且仍然只有與我們的討論相關(guān)的字段。從圖中可以看出，異常的type_info可以通過excpt_info結(jié)構(gòu)得到。由于異常處理程序需要拷貝異常對(duì)象(在調(diào)用catch塊之前)，也需要消除掉它(在調(diào)用catch塊之后)，所以編譯器在這個(gè)結(jié)構(gòu)中同時(shí)提供了異常的拷貝構(gòu)造函數(shù)、大小和析構(gòu)函數(shù)的信息。在c

24、atch塊的參數(shù)是基類，而異常是派生類時(shí)，異常處理程序也應(yīng)該調(diào)用catch塊。然而，這種情況下，比較它們的type_info絕對(duì)是不相等，因?yàn)樗鼈儽緛砭筒皇窍嗤念愋?。而且，type_info類也沒有提供任何其他函數(shù)或運(yùn)算符來指出一個(gè)類是另一個(gè)類的基類。但異常處理程序還必須得去調(diào)用catch塊！為了解決這個(gè)問題，編譯器只能為處理程序提供更多的信息：如果異常是派生類，那么etypeinfo_table(通過excpt_info訪問)將包含多個(gè)指向etype_info(擴(kuò)展了type_info，這個(gè)名字是我啟的)的指針，它們分別指向了各個(gè)基類的etype_info。這樣，處理程序就可以把catch

25、塊的參數(shù)和所有這些type_info比較，只要有一個(gè)相同，就調(diào)用catch塊。在結(jié)束這一部分之前，還有最后一個(gè)問題：異常處理程序是怎么知道異常和excpt_info結(jié)構(gòu)的?下面我就要回答這個(gè)問題。VC+會(huì)把throw語句翻譯成下面的樣子：/throw E()；/編譯器會(huì)為E生成excpt_info結(jié)構(gòu)E e=E()；/在棧上創(chuàng)建異常_CxxThrowException(&e,E_EXCPT_INFO_ADDR)；_CxxThrowException會(huì)把控制權(quán)連帶它的兩個(gè)參數(shù)都交給操作系統(tǒng)(控制權(quán)轉(zhuǎn)移是通過軟件中斷實(shí)現(xiàn)的，請(qǐng)參見RaiseException)。而操作系統(tǒng)，在為調(diào)用異?；卣{(diào)函數(shù)做準(zhǔn)

26、備時(shí)，會(huì)把這兩個(gè)參數(shù)打包到一個(gè)_EXCEPTION_RECORD結(jié)構(gòu)中。接著，它從EXCEPTION_REGISTRATION鏈表的頭結(jié)點(diǎn)(由FS：0指向)開始，依次調(diào)用各節(jié)點(diǎn)的異常處理程序。而且，指向當(dāng)前EXCEPTION_REGISTRATION結(jié)構(gòu)的指針也會(huì)作為異常處理程序的第二個(gè)參數(shù)出現(xiàn)。前面已經(jīng)說過，VC+中的每個(gè)函數(shù)都在棧上創(chuàng)建并注冊(cè)了EXCEPTION_REGISTRATION結(jié)構(gòu)。所以傳遞這個(gè)參數(shù)可以讓處理程序知道很多重要信息，比如說：EXCEPTION_REGISTRATION的id字段(用于查找catch塊)、函數(shù)的棧楨(用于清理?xiàng)E)和EXCEPTION_REGISTRA

27、TION結(jié)點(diǎn)在異常鏈表中的位置(用于堆棧展開)等。第一個(gè)參數(shù)是指向_EXCEPTION_RECORD結(jié)構(gòu)的指針，通過它可以找到異常和它的excpt_info結(jié)構(gòu)。下面是excpt.h中定義的異?；卣{(diào)函數(shù)的原型：EXCEPTION_DISPOSITION(*handler)(_EXCEPTION_RECORD*ExcRecord,void*EstablisherFrame,_CONTEXT*ContextRecord,void*DispatcherContext)；后兩個(gè)參數(shù)和我們的討論關(guān)系不大。函數(shù)的返回值是一個(gè)枚舉類型(也在excpt.h中定義)，我前面已經(jīng)說過，如果處理程序找不到catch

28、塊，它就會(huì)向系統(tǒng)返回ExceptionContinueSearch，對(duì)本文而言，我們只要知道這一個(gè)返回值就行了。_EXCEPTION_RECORD結(jié)構(gòu)是在winnt.h中定義的：struct _EXCEPTION_RECORD DWORD ExceptionCode；DWORD ExceptionFlags；_EXCEPTION_RECORD*ExcRecord；PVOID ExceptionAddress；DWORD NumberParameters；DWORD ExceptionInformation15；EXCEPTION_RECORD；ExceptionInformation數(shù)組中元素

29、的個(gè)數(shù)和類型取決于ExceptionCode字段。如果是C+異常(異常代碼是0xe06d7363，源于throw語句)，那么數(shù)組中將包含指向異常和excpt_info結(jié)構(gòu)的指針；如果是其他異常，那數(shù)組中基本上就不會(huì)有什么內(nèi)容，這些異常包括除零溢出、訪問違例等，你可以在winnt.h中找到它們的異常代碼。ExceptionFlags字段用于告訴異常處理程序應(yīng)該采取什么操作。如果它是EH_UNWINDING(見Except.inc)，那是說堆棧正在展開，這時(shí)，處理程序要清理?xiàng)E，然后返回。否則處理程序應(yīng)該在函數(shù)中查找catch塊并調(diào)用它。清理?xiàng)E意味著必須找到異常發(fā)生時(shí)生存在棧楨上的所有局部對(duì)象,

30、并調(diào)用其析構(gòu)函數(shù)，下一節(jié)我們將就此進(jìn)行詳細(xì)討論。清理?xiàng)EC+標(biāo)準(zhǔn)明確指出：堆棧展開工作必須調(diào)用異常發(fā)生時(shí)所有生存的局部對(duì)象的析構(gòu)函數(shù)。如下面的代碼：int g_i=0；void foo()T o1,o2；T o3；10/g_i；/這里會(huì)發(fā)生異常T o4；/.foo有o1、o2、o3、o4四個(gè)局部對(duì)象，但異常發(fā)生時(shí)，o3已經(jīng)死亡，o4還未出生，所以異常處理程序應(yīng)該只調(diào)用o1和o2的析構(gòu)函數(shù)。前面已經(jīng)說過，編譯器會(huì)在函數(shù)的很多地方安插代碼來記錄當(dāng)前的運(yùn)行狀態(tài)。實(shí)際上，編譯器在函數(shù)中設(shè)置了一些關(guān)鍵區(qū)域，并為它們分配了id，進(jìn)入關(guān)鍵區(qū)域時(shí)要記錄它的id，退出時(shí)恢復(fù)前一個(gè)id。try塊就是一個(gè)例子,其i

31、d就是start id。所以，在try塊的入口，編譯器會(huì)把它的start id記到棧楨上去。局部對(duì)象從創(chuàng)建到銷毀也確定了一個(gè)關(guān)鍵區(qū)域，或者，換句話說，編譯器給每個(gè)局部對(duì)象分配了唯一的id，例如下面的程序：void foo()T t1；/.編譯器會(huì)在t1的定義后面(也就是t1創(chuàng)建以后),把它的id寫到棧楨上：void foo()T t1；_id=t1_id；/編譯器插入的語句/.上面的_id是編譯器偷偷創(chuàng)建的局部變量，它的位置與EXCEPTION_REGISTRATION的id字段重疊。類似的，在調(diào)用對(duì)象的析構(gòu)函數(shù)前，編譯器會(huì)恢復(fù)前一個(gè)關(guān)鍵區(qū)域的id。清理?xiàng)E時(shí)，異常處理程序讀出id的值(通過E

32、XCEPTION_REGISTRATION結(jié)構(gòu)的id字段或棧楨指針EBP下面的4個(gè)字節(jié)來訪問)。這個(gè)id可以表明，函數(shù)在運(yùn)行到與它相關(guān)聯(lián)的那個(gè)點(diǎn)之前沒有發(fā)生異常。所有在這一點(diǎn)之前定義的對(duì)象都已初始化，應(yīng)該調(diào)用這些對(duì)象中的一部分或全部對(duì)象的析構(gòu)函數(shù)。請(qǐng)注意某些對(duì)象是屬于子塊(如前面代碼中的o3)的，發(fā)生異常時(shí)可能已經(jīng)銷毀了，不應(yīng)該調(diào)用它們的析構(gòu)函數(shù)。編譯器還為函數(shù)生成了另一個(gè)數(shù)據(jù)結(jié)構(gòu)-堆棧展開表(unwindtable，我啟的名字)，它是一個(gè)unwind結(jié)構(gòu)的數(shù)組，可通過funcinfo來訪問，如圖4所示。函數(shù)的每個(gè)關(guān)鍵區(qū)域都有一個(gè)unwind結(jié)構(gòu)，這些結(jié)構(gòu)在展開表中出現(xiàn)的次序和它們所對(duì)應(yīng)的區(qū)域

33、在函數(shù)中的出現(xiàn)次序完全相同。一般unwind結(jié)構(gòu)也會(huì)關(guān)聯(lián)一個(gè)對(duì)象(別忘了，每個(gè)對(duì)象的定義都開辟了關(guān)鍵區(qū)域，并有id與其對(duì)應(yīng))，它里面有如何銷毀這個(gè)對(duì)象的信息。每當(dāng)編譯器碰到對(duì)象定義，它就生成一小段代碼，這段代碼知道對(duì)象在棧楨上的地址(就是它相對(duì)于棧楨指針的偏移)，并能銷毀它。unwind結(jié)構(gòu)中有一個(gè)字段用于保存這段代碼的入口地址：typedef void(*CLEANUP_FUNC)()；struct unwind int prev；CLEANUP_FUNC cf；try塊對(duì)應(yīng)的unwind結(jié)構(gòu)的cf字段是空值NULL，因?yàn)闆]有與它對(duì)應(yīng)的對(duì)象，所以也沒有東西需要它去銷毀。通過prev字段，這些

34、unwind結(jié)構(gòu)也形成了一個(gè)鏈表。異常處理程序清理?xiàng)E時(shí)，會(huì)讀取當(dāng)前的id值，以它為索引取得展開表中對(duì)應(yīng)的項(xiàng)，并調(diào)用其第二個(gè)字段指向的清理代碼，這樣，那個(gè)與之關(guān)聯(lián)的對(duì)象就被銷毀了。然后，處理程序?qū)⒁援?dāng)前unwind結(jié)構(gòu)的prev字段為索引，繼續(xù)在展開表中找下一個(gè)unwind結(jié)構(gòu)，調(diào)用其清理代碼。這一過程將一直重復(fù)，直到鏈表的結(jié)尾(prev的值是-1)。圖6畫出了本節(jié)開始時(shí)提到的那段代碼的堆棧展開表?，F(xiàn)在把new運(yùn)算符也加進(jìn)來，對(duì)于下面的代碼：T*p=new T()；系統(tǒng)會(huì)首先為T分配內(nèi)存，然后調(diào)用它的構(gòu)造函數(shù)。所以，如果構(gòu)造函數(shù)拋出了異常，系統(tǒng)就必須釋放這些內(nèi)存。因此，動(dòng)態(tài)創(chuàng)建那些擁有有為的構(gòu)

35、造函數(shù)的類型時(shí)，VC+也為new運(yùn)算符分配了id，并且堆棧展開表中也有與其對(duì)應(yīng)的項(xiàng)，其清理代碼將釋放分配的內(nèi)存空間。調(diào)用構(gòu)造函數(shù)前，編譯器把new運(yùn)算符的id存到EXCEPTION_REGISTRATION結(jié)構(gòu)中，構(gòu)造函數(shù)順利返回后，它再把id恢復(fù)成原來的值。更進(jìn)一步說，構(gòu)造函數(shù)拋出異常時(shí)，對(duì)象可能剛剛構(gòu)造了一部分，如果它有子成員對(duì)象或子基類對(duì)象，并且發(fā)生異常時(shí)它們中的一部分已經(jīng)構(gòu)造完成的話，就必須調(diào)用這些對(duì)象的析構(gòu)函數(shù)。和普通函數(shù)一樣，編譯器也給構(gòu)造函數(shù)生成了相關(guān)的數(shù)據(jù)來幫助完成這個(gè)任務(wù)。展開堆棧時(shí)，異常處理程序調(diào)用的是用戶定義的析構(gòu)函數(shù)，這一點(diǎn)你必須注意，因?yàn)樗灿锌赡軖伋霎惓?！C+標(biāo)準(zhǔn)規(guī)

36、定堆棧展開過程中，析構(gòu)函數(shù)不能拋出異常，否則系統(tǒng)將調(diào)用std：terminate。實(shí)現(xiàn)本節(jié)我們討論其他三個(gè)有待詳細(xì)解釋的問題：a)如何安裝異常處理程序b)catch塊重新拋出異常或拋出新異常時(shí)應(yīng)該如何處理c)如何對(duì)所有線程提供異常處理支持隨同本文，有一個(gè)演示項(xiàng)目，查看其中的readme.txt文件可以得到一些編譯方面的幫助。第一項(xiàng)任務(wù)是安裝異常處理程序，也就是把VC+的處理程序替換掉。從前面的討論中，我們已經(jīng)清楚地知道_CxxFrameHandler函數(shù)是VC+所有異常處理工作的入口。編譯器為每個(gè)函數(shù)都生成一段代碼，它們?cè)诎l(fā)生異常時(shí)被調(diào)用，把相應(yīng)的funcinfo結(jié)構(gòu)的指針交給_CxxFram

37、eHandler。install_my_handler()函數(shù)會(huì)改寫_CxxFrameHandler的入口處的代碼，讓程序跳轉(zhuǎn)到my_exc_handler()函數(shù)。不過，_CxxFrameHandler位于只讀的內(nèi)存頁，對(duì)它的任何寫操作都會(huì)導(dǎo)致訪問違例，所以必須首先用VirtualProtectEx把該內(nèi)存頁的保護(hù)方式改成可讀寫，等改寫完畢后，再改回只讀。寫入的數(shù)據(jù)是一個(gè)jmp_instr結(jié)構(gòu)。/install_my_handler.cpp#include windows.h#includeinstall_my_handler.h/C+默認(rèn)的異常處理程序externCEXCEPTION_DI

38、SPOSITION _CxxFrameHandler(struct _EXCEPTION_RECORD*ExceptionRecord,void*EstablisherFrame,struct _CONTEXT*ContextRecord,void*DispatcherContext)；namespace char cpp_handler_instructions5；bool saved_handler_instructions=false；namespace my_handler/我的異常處理程序EXCEPTION_DISPOSITION my_exc_handler(struct _EXC

39、EPTION_RECORD*ExceptionRecord,void*EstablisherFrame,struct _CONTEXT*ContextRecord,void*DispatcherContext)throw()；#pragma pack(push,1)struct jmp_instr unsigned char jmp；DWORD offset；#pragma pack(pop)bool WriteMemory(void*loc,void*buffer,int size)HANDLE hProcess=GetCurrentProcess()；/把包含內(nèi)存范圍loc，loc+siz

40、e的頁面的保護(hù)方式改成可讀寫DWORD old_protection；BOOL ret=VirtualProtectEx(hProcess,loc,size,PAGE_READWRITE,&old_protection)；if(ret=FALSE)return false；ret=WriteProcessMemory(hProcess,loc,buffer,size,NULL)；/恢復(fù)原來的保護(hù)方式DWORD o2；VirtualProtectEx(hProcess,loc,size,old_protection,&o2)；return(ret=TRUE)；bool ReadMemory(vo

41、id*loc,void*buffer,DWORD size)HANDLE hProcess=GetCurrentProcess()；DWORD bytes_read=0；BOOL ret=ReadProcessMemory(hProcess,loc,buffer,size,&bytes_read)；return(ret=TRUE&bytes_read=size)；bool install_my_handler()void*my_hdlr=my_exc_handler；void*cpp_hdlr=_CxxFrameHandler；jmp_instr jmp_my_hdlr；jmp_my_hdlr

42、.jmp=0xE9；/從_CxxFrameHandler+5開始計(jì)算偏移，因?yàn)閖mp指令長5字節(jié)jmp_my_hdlr.offset=reinterpret_cast(my_hdlr)-(reinterpret_cast(cpp_hdlr)+5)；if(！saved_handler_instructions)if(！ReadMemory(cpp_hdlr,cpp_handler_instructions,sizeof(cpp_handler_instructions)return false；saved_handler_instructions=true；return WriteMemory(

43、cpp_hdlr,&jmp_my_hdlr,sizeof(jmp_my_hdlr)；bool restore_cpp_handler()if(！saved_handler_instructions)return false；else void*loc=_CxxFrameHandler；return WriteMemory(loc,cpp_handler_instructions,sizeof(cpp_handler_instructions)；編譯指令#pragma pack(push,1)告訴編譯器不要在jmp_instr結(jié)構(gòu)中填充任何用于對(duì)齊的空間。沒有這條指令，jmp_instr的大小將

44、是8字節(jié)，而我們需要它是5字節(jié)?，F(xiàn)在重新回到異常處理這個(gè)主題上來。調(diào)用catch塊時(shí)，它可能重新拋出異常或拋出新異常。前一種情況下，異常處理程序必須繼續(xù)傳播(propagate)當(dāng)前異常；后一種情況下，它需要在繼續(xù)之前銷毀原來的異常。此時(shí)，處理程序要面對(duì)兩個(gè)難題：如何知道異常是源于catch塊還是程序的其他部分和如何跟蹤原來的異常。我的解決方法是：在調(diào)用catch塊之前，把當(dāng)前異常保存在exception_storage對(duì)象中，并注冊(cè)一個(gè)專用于catch塊的異常處理程序-catch_block_protector。調(diào)用get_exception_storage()函數(shù)，就能得到exceptio

45、n_storage對(duì)象：exception_storage*p=get_exception_storage()；p-set(pexc,pexc_info)；注冊(cè)catch_block_protector；調(diào)用catch塊；/.這樣，當(dāng)catch塊(重新)拋出異常時(shí)，程序?qū)?huì)執(zhí)行catch_block_protector。如果是拋出了新異常，這個(gè)函數(shù)可以從exception_storage對(duì)象中分離出前一個(gè)異常并銷毀它；如果是重新拋出原來的異常(可以通過ExceptionInformation數(shù)組的前兩個(gè)元素知道是新異常還是舊異常，后一種情況下著兩個(gè)元素都是0，參見下面的代碼)，就通過拷貝Exc

46、eptionInformation數(shù)組來繼續(xù)傳播它。下面的代碼就是catch_block_protector()函數(shù)的實(shí)現(xiàn)。/-/如果這個(gè)處理程序被調(diào)用了，可以斷定是catch塊(重新)拋出了異常。/異常處理程序(my_handler)在調(diào)用catch塊之前注冊(cè)了它。其任務(wù)是判斷/catch塊拋出了新異常還是重新拋出了原來的異常，并采取相應(yīng)的操作。/在前一種情況下，它需要銷毀傳遞給catch塊的前一個(gè)異常對(duì)象；在后一種/情況下，它必須找到原來的異常并將其保存到ExceptionRecord中供異常/處理程序使用。/-EXCEPTION_DISPOSITION catch_block_prote

47、ctor(_EXCEPTION_RECORD*ExceptionRecord,void*EstablisherFrame,struct _CONTEXT*ContextRecord,void*DispatcherContext)throw()EXCEPTION_REGISTRATION*pFrame；pFrame=reinterpret_cast EXCEPTION_REGISTRATION*(EstablisherFrame)；if(！(ExceptionRecord-ExceptionFlags&(_EXCEPTION_UNWINDING|_EXCEPTION_EXIT_UNWIND)vo

48、id*pcur_exc=0,*pprev_exc=0；const excpt_info*pexc_info=0,*pprev_excinfo=0；exception_storage*p=get_exception_storage()；pprev_exc=p-get_exception()；pprev_excinfo=p-get_exception_info()；p-set(0,0)；bool cpp_exc=ExceptionRecord-ExceptionCode=MS_CPP_EXC；get_exception(ExceptionRecord,&pcur_exc)；get_excpt_in

49、fo(ExceptionRecord,&pexc_info)；if(cpp_exc&0=pcur_exc&0=pexc_info)/重新拋出ExceptionRecord-ExceptionInformation1=reinterpret_cast DWORD(pprev_exc)；ExceptionRecord-ExceptionInformation2=reinterpret_cast DWORD(pprev_excinfo)；else exception_helper：destroy(pprev_exc,pprev_excinfo)；return ExceptionContinueSearch；下面是get_exception_storage()函數(shù)的一個(gè)實(shí)現(xiàn)：exception_storage*get_exception_storage()static exception_storage es；return&es；在單線程程序中，這是一個(gè)完美的實(shí)現(xiàn)。但在多線程中，這就是個(gè)災(zāi)難了，想象一下多個(gè)線程訪問它，并把異常對(duì)象保存在里面的情景吧。由于每個(gè)線程都有自己的堆棧和