C異常處理機(jī)制

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

2、之后，程序中的所有異常，從它們被拋出到堆棧展開（stack unwinding），再到調(diào)用catch塊，最后到程序恢復(fù)正常運行，都將由我的異常處理庫來管理。與其它C+特性一樣，C+標(biāo)準(zhǔn)并沒有規(guī)定編譯器應(yīng)該如何來實現(xiàn)異常處理。這意味著每一個編譯器的提供商都可以用它們認(rèn)為恰當(dāng)?shù)姆绞絹韺崿F(xiàn)它。下面我會描述一下VC+是怎么做的，但即使你使用其它的編譯器或操作系統(tǒng)，本文也應(yīng)該會是一篇很好的學(xué)習(xí)材料。VC+的實現(xiàn)方式是以windows系統(tǒng)的結(jié)構(gòu)化異常處理（SEH）為基礎(chǔ)的。 結(jié)構(gòu)化異常處理概述在本文的討論中，我認(rèn)為異?；蛘呤潜幻鞔_的拋出的，或者是由于除零溢出、空指針訪問等引起的。當(dāng)它發(fā)生時會產(chǎn)生一個中斷，

3、接下來控制權(quán)就會傳遞到操作系統(tǒng)的手中。操作系統(tǒng)將調(diào)用異常處理程序，檢查從異常發(fā)生位置開始的函數(shù)調(diào)用序列，進(jìn)行堆棧展開和控制權(quán)轉(zhuǎn)移。Windows定義了結(jié)構(gòu)“EXCEPTION_REGISTRATION”，使我們能夠向操作系統(tǒng)注冊自己的異常處理程序。 struct EXCEPTION_REGISTRATIONEXCEPTION_REGISTRATION* prev;DWORD handler; 注冊時，只需要創(chuàng)建這樣一個結(jié)構(gòu)，然后把它的地址放到FS段偏移0的位置上去就行了。下面這句匯編代碼演示了這一操作：mov FS:0, exc_regpprev字段用于建立一個EXCEPTION_REGIST

4、RATION結(jié)構(gòu)的鏈表，每次注冊新的EXCEPTION_REGISTRATION時，我們都要把原來注冊的那個的地址存到prev中。那么，那個異?；卣{(diào)函數(shù)長什么樣呢？在excpt.h中，windows定義了它的原形：EXCEPTION_DISPOSITION (*handler( _EXCEPTION_RECORD *ExcRecord, void* EstablisherFrame, _CONTEXT *ContextRecord, void* DispatcherContext; 不要管它的參數(shù)和返回值，我們先來看一個簡單的例子。下面的程序注冊了一個異常處理程序，然后通過除以零產(chǎn)生了一個異常

5、。異常處理程序捕獲了它，打印了一條消息就完事大吉并退出了。#include #include using std:cout; using std:endl; struct EXCEPTION_REGISTRATION EXCEPTION_REGISTRATION* prev; DWORD handler; ; EXCEPTION_DISPOSITION myHandler( _EXCEPTION_RECORD *ExcRecord, void * EstablisherFrame, _CONTEXT *ContextRecord, void * DispatcherContext cout &

6、lt;< "In the exception handler" << endl; cout << "Just a demo. exiting." << endl; exit(0; return ExceptionContinueExecution; /不會運行到這 int g_div = 0; void bar( /初始化一個EXCEPTION_REGISTRATION結(jié)構(gòu) EXCEPTION_REGISTRATION reg, *preg = ® reg.handler = (DWORDmyHandl

7、er; /取得當(dāng)前異常處理鏈的“頭” DWORD prev; _asm mov EAX, FS:0 mov prev, EAX reg.prev = (EXCEPTION_REGISTRATION* prev; /注冊！ _asm mov EAX, preg mov FS:0, EAX /產(chǎn)生一個異常 int j = 10 / g_div; /異常，除零溢出 int main( bar(; return 0; /*-輸出- In the exception handler Just a demo. exiting. -*/注意EXCEPTION_REGISTRATION必須定義在棧上，并且必須

8、位于比上一個結(jié)點更低的內(nèi)存地址上，Windows對此有嚴(yán)格要求，達(dá)不到的話，它就會立刻終止進(jìn)程。函數(shù)和堆棧堆棧是用來保存局部對象的連續(xù)內(nèi)存區(qū)。更明確的說，每個函數(shù)都有一個相關(guān)的棧楨（stack frame）來保存它所有的局部對象和表達(dá)式計算過程中用到的臨時對象，至少理論上是這樣的。但現(xiàn)實中，編譯器經(jīng)常會把一些對象放到寄存器中以便能以更快的速度訪問。堆棧是一個處理器（CPU）層次的概念，為了操縱它，處理器提供了一些專用的寄存器和指令。 圖1是一個典型的堆棧，它示出了函數(shù)foo調(diào)用bar，bar又調(diào)用widget時的情景。請注意堆棧是向下增長的，這意味著新壓入的項的地址低于原有項的地址。通常編譯器

9、使用EBP寄存器來指示當(dāng)前活動的棧楨。本例中，CPU正在運行widget，所以圖中的EBP指向了widget的棧楨。編譯器在編譯時將所有局部對象解析成相對于棧楨指針（EBP）的固定偏移，函數(shù)則通過棧楨指針來間接訪問局部對象。舉個例子，典型的，widget訪問它的局部變量時就是通過訪問棧楨指針以下的、有著確定位置的幾個字節(jié)來實現(xiàn)的，比如說EBP-24。上圖中也畫出了ESP寄存器，它叫棧指針，指向棧的最后一項。在本例中，ESP指著widget的棧楨的末尾，這也是下一個棧楨（如果它被創(chuàng)建的話）的開始位置。處理器支持兩種類型的棧操作：壓棧（push）和彈棧（pop）。比如，pop EAX的作用是從ES

10、P所指的位置讀出4字節(jié)放到EAX寄存器中，并把ESP加上（記住，棧是向下增長的）4（在32位處理器上）；類似的，push EBP的作用是把ESP減去4，然后將EBP的值放到ESP指向的位置中去。 編譯器編譯一個函數(shù)時，會在它的開頭添加一些代碼來為其創(chuàng)建并初始化棧楨，這些代碼被稱為序言（prologue）；同樣，它也會在函數(shù)的結(jié)尾處放上代碼來清除棧楨，這些代碼叫做尾聲（epilogue）。 一般情況下，序言是這樣的：Push EBP ; 把原來的棧楨指針保存到棧上 Mov EBP, ESP ; 激活新的棧楨 Sub ESP, 10 ; 減去一個數(shù)字，讓ESP指向棧楨的末尾第一條指令把原來的棧楨指

11、針EBP保存到棧上；第二條指令通過讓EBP指向主調(diào)函數(shù)的EBP的保存位置來激活被調(diào)函數(shù)的棧楨；第三條指令把ESP減去了一個數(shù)字，這樣ESP就指向了當(dāng)前棧楨的末尾，而這個數(shù)字是函數(shù)要用到的所有局部對象和臨時對象的大小。編譯時，編譯器知道函數(shù)的所有局部對象的類型和“體積”，所以，它能很容易的計算出棧楨的大小。 尾聲所做的正好和序言相反，它必須把當(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遇

12、到返回指令，它就要做以下兩件事：把返回地址從棧中彈出，然后跳轉(zhuǎn)到那個地址去。返回地址是主調(diào)函數(shù)執(zhí)行call指令調(diào)用被調(diào)函數(shù)時自動壓棧的。Call指令執(zhí)行時，會先把緊隨在它后面的那條指令的地址（被調(diào)函數(shù)的返回地址）壓入棧中，然后跳轉(zhuǎn)到被調(diào)函數(shù)的開始位置。圖2更詳細(xì)的描繪了運行時的堆棧。如圖所示，主調(diào)函數(shù)把被調(diào)函數(shù)的參數(shù)也壓進(jìn)了堆棧，所以參數(shù)也是棧楨的一部分。函數(shù)返回后，主調(diào)函數(shù)需要移除這些參數(shù)，它通過把所有參數(shù)的總體積加到ESP上來達(dá)到目的，而這個體積可以在編譯時知道： Add ESP, args_size當(dāng)然，也可以把參數(shù)的總體積寫在被調(diào)函數(shù)的返回指令的后面，讓被調(diào)函數(shù)去移除參數(shù)，下面的指令就

13、在返回主調(diào)函數(shù)前從棧中移去了24個字節(jié)：Ret 24取決于被調(diào)函數(shù)的調(diào)用約定（call convention），這兩種方式每次只能用一個。你還要注意的是每個線程都有自己獨立的堆棧。C+和異常 回憶一下我在第一節(jié)中介紹的EXCEPTION_REGISTRATION結(jié)構(gòu)，我們曾用它向操作系統(tǒng)注冊了發(fā)生異常時要被調(diào)用的回調(diào)函數(shù)。VC+也是這么做的，不過它擴(kuò)展了這個結(jié)構(gòu)的語義，在它的后面添加了兩個新字段：struct EXCEPTION_REGISTRATION EXCEPTION_REGISTRATION* prev; DWORD handler; int id; DWORD ebp; ; VC+會

14、為絕大部分函數(shù)添加一個EXCEPTION_REGISTRATION類型的局部變量，它的最后一個字段（ebp）與棧楨指針指向的位置重疊。函數(shù)的序言創(chuàng)建這個結(jié)構(gòu)并把它注冊給操作系統(tǒng)，尾聲則恢復(fù)主調(diào)函數(shù)的EXCEPTION_REGISTRATION。id字段的意義我將在下一節(jié)介紹。VC+編譯函數(shù)時會為它生成兩部分?jǐn)?shù)據(jù)：a）異?；卣{(diào)函數(shù) b）一個包含函數(shù)重要信息的數(shù)據(jù)結(jié)構(gòu)，這些信息包括catch塊、這些塊的地址和這些塊所關(guān)心的異常的類型等等。我把這個結(jié)構(gòu)稱為funcinfo，有關(guān)它的詳細(xì)討論也在下一節(jié)。 圖3是考慮了異常處理之后的運行時堆棧。widget的異?；卣{(diào)函數(shù)位于由FS:0指向的異常處理鏈的開

15、始位置（這是由widget的序言設(shè)置的）。異常處理程序把widget的funcinfo結(jié)構(gòu)的地址交給函數(shù)_CxxFrameHandler，_CxxFrameHandler會檢查這個結(jié)構(gòu)看函數(shù)中有沒有catch塊對當(dāng)前的異常感興趣。如果沒有的話，它就返回ExceptionContinueSearch給操作系統(tǒng)，于是操作系統(tǒng)會從異常處理鏈表中取得下一個結(jié)點，并調(diào)用它的異常處理程序（也就是調(diào)用當(dāng)前函數(shù)的那個函數(shù)的異常處理程序）。 這一過程將一直進(jìn)行下去直到處理程序找到一個能處理當(dāng)前異常的catch塊為止，這時它就不再返回操作系統(tǒng)了。但是在調(diào)用catch塊之前（由于有funcinfo結(jié)構(gòu)，所以知道ca

16、tch塊的入口，參見圖3），必須進(jìn)行堆棧展開，也就是清理掉當(dāng)前函數(shù)的棧楨下面的所有其他的棧楨。這個操作稍微有點復(fù)雜，因為：異常處理程序必須找到異常發(fā)生時生存在這些棧楨上的所有局部對象，并依次調(diào)用它們的析構(gòu)函數(shù)。后面我將對此進(jìn)行詳細(xì)介紹。異常處理程序把這項工作委托給了各個棧楨自己的異常處理程序。從FS:0指向的異常處理鏈的第一個結(jié)點開始，它依次調(diào)用每個結(jié)點的處理程序，告訴它堆棧正在展開。與之相呼應(yīng)，這些處理程序會調(diào)用每個局部對象的析構(gòu)函數(shù)，然后返回。此過程一直進(jìn)行到與異常處理程序自身相對應(yīng)的那個結(jié)點為止。 由于catch塊是函數(shù)的一部分，所以它使用的也是函數(shù)的棧楨。因此，在調(diào)用catch塊之前，

17、異常處理程序必須激活它所隸屬的函數(shù)的棧楨。其次，每個catch塊都只接受一個參數(shù)，其類型是它希望捕獲的異常的類型。異常處理程序必須把異常對象本身或者是異常對象的引用拷貝到catch塊的棧楨上，編譯器在funcinfo中記錄了相關(guān)信息，處理程序根據(jù)這些信息就能知道到哪去拷貝異常對象了?？截愅戤惓２⒓せ顥E后，處理程序?qū)⒄{(diào)用catch塊。而catch塊將把控制權(quán)下一步要轉(zhuǎn)移到的地址返回來。請注意：雖然這時堆棧已經(jīng)展開，棧楨也都被清除了，但它們占據(jù)的內(nèi)存空間并沒有被覆蓋，所有的數(shù)據(jù)都還好好的待在棧上。這是因為異常處理程序仍在執(zhí)行，象其他函數(shù)一樣，它也需要棧來存放自己的局部對象，而其棧楨就位于發(fā)生異常

18、的那個函數(shù)的棧楨的下面。catch塊返回以后，異常處理程序需要“殺掉”異常對象。此后，它讓ESP指向目標(biāo)函數(shù)（控制權(quán)要轉(zhuǎn)移到的那個函數(shù)）的棧楨的末尾這樣就把（包括它自己的在內(nèi)的）所有棧楨都刪除了，然后再跳轉(zhuǎn)到catch塊返回的那個地址去，就勝利的完成整個異常處理任務(wù)了。但它怎么知道目標(biāo)函數(shù)的棧楨末尾在哪呢？事實上它沒法知道，所以編譯器把這個地址保存到了棧楨上（由前言來完成），如圖3所示，棧楨指針EBP下面第16個字節(jié)就是。當(dāng)然，catch塊也可能拋出新異常，或者是將原來的異常重新拋出。處理程序必須對此有所準(zhǔn)備。如果是拋出新異常，它必須殺掉原來的那個；而如果是重新拋出原來的異常，它必須能繼續(xù)傳播

19、（propagate）這個異常。這里我要特別強(qiáng)調(diào)一點：由于每個線程有自己獨立的堆棧，所以每個線程也都有自己獨立的、由FS:0指向的EXCEPTION_REGISTRATION鏈。C+和異常2圖4是funcinfo的布局，注意這里的字段名可能與VC+編譯器實際使用的不完全一致，而且我也只給出了和我們的討論相關(guān)的字段。堆棧展開表（unwind table）的結(jié)構(gòu)留到下節(jié)再討論。 異常處理程序在函數(shù)中查找catch塊時，它首先要判斷異常發(fā)生的位置是否在當(dāng)前函數(shù)（發(fā)生異常的那個函數(shù)）的一個try塊中。是則查找與此try塊相關(guān)的catch塊表，否則直接返回。 先來看看它怎樣找try塊。編譯時，編譯器給每

20、個try塊都分配了start id和end id。通過funcinfo結(jié)構(gòu)，異常處理程序可以訪問這兩個id，見圖4。編譯器為函數(shù)中的每個try塊都生成了相關(guān)的數(shù)據(jù)結(jié)構(gòu)。 上一節(jié)中，我說過VC+給EXCEPTION_REGISTRATION結(jié)構(gòu)加上了一個id字段。回憶一下圖3，這個結(jié)構(gòu)位于函數(shù)的棧楨上。異常發(fā)生時，處理程序讀出這個值，看它是否在try塊的兩個id確定的區(qū)間start id，end id中。是的話，異常就發(fā)生在這個try塊中；否則繼續(xù)查看try塊表中的下一個try塊。誰負(fù)責(zé)更新id的值，它的值又應(yīng)該是什么呢？原來，編譯器會在函數(shù)的多個位置安插代碼來更新id的值，以反應(yīng)程序的實時運行

21、狀態(tài)。比如說，編譯器會在進(jìn)入try塊的地方加上一條語句，把try塊的start id寫到棧楨上。找到try塊后，處理程序就遍歷與其關(guān)聯(lián)的catch塊表，看是否有對當(dāng)前異常感興趣的catch塊。在try塊發(fā)生嵌套時，異常將既源于內(nèi)層try塊，也源于外層try塊。這種情況下，處理程序應(yīng)該按先內(nèi)后外的順序查找catch塊。但它其實沒必要關(guān)心這些，因為，在try塊表中，VC+總是把內(nèi)層try塊放在外層try塊的前面。異常處理程序還有一個難題就是“如何根據(jù)catch塊的相關(guān)數(shù)據(jù)結(jié)構(gòu)判斷這個catch塊是否愿意處理當(dāng)前異常”。這是通過比較異常的類型和catch塊的參數(shù)的類型來完成的。例如下面這個程序：vo

22、id foo( try throw E(; catch(H /. 如果H和E的類型完全相同的話，catch塊就要捕獲這個異常。這意味著處理程序必須在運行時進(jìn)行類型比較，對C等語言來說，這是不可能的,因為它們無法在運行時得到對象的類型。C+則不同，它有了運行時類型識別（runtime type identification，RTTI），并提供了運行時類型比較的標(biāo)準(zhǔn)方法。C+在標(biāo)準(zhǔn)頭文件中定義了type_info類，它能在運行時代表一個類型。catch塊數(shù)據(jù)結(jié)構(gòu)的第二個字段（ptype_info，見圖4）是一個指向type_info結(jié)構(gòu)的指針，它在運行時就代表catch塊的參數(shù)類型。type_in

23、fo也重載了=運算符，能夠指出兩種類型是否完全相同。這樣，異常處理程序只要比較（調(diào)用=運算符）catch塊參數(shù)的type_info（可以通過catch塊的相關(guān)數(shù)據(jù)結(jié)構(gòu)來訪問）和異常的type_info是否相同，就能知道catch塊是不是愿意捕獲當(dāng)前異常了。catch塊的參數(shù)類型可以通過funcinfo結(jié)構(gòu)得到，但異常的type_info從哪來呢？當(dāng)編譯器碰到 throw E(;這條語句時，它會為異常生成一個excpt_info結(jié)構(gòu)，如圖5所示。還是要提醒你注意這里用的名字可能與VC+使用的不一致，而且仍然只有與我們的討論相關(guān)的字段。從圖中可以看出，異常的type_info可以通過excpt_i

24、nfo結(jié)構(gòu)得到。由于異常處理程序需要拷貝異常對象（在調(diào)用catch塊之前），也需要消除掉它（在調(diào)用catch塊之后），所以編譯器在這個結(jié)構(gòu)中同時提供了異常的拷貝構(gòu)造函數(shù)、大小和析構(gòu)函數(shù)的信息。 在catch塊的參數(shù)是基類，而異常是派生類時，異常處理程序也應(yīng)該調(diào)用catch塊。然而，這種情況下，比較它們的type_info絕對是不相等，因為它們本來就不是相同的類型。而且，type_info類也沒有提供任何其他函數(shù)或運算符來指出一個類是另一個類的基類。但異常處理程序還必須得去調(diào)用catch塊！為了解決這個問題，編譯器只能為處理程序提供更多的信息：如果異常是派生類，那么etypeinfo_table

25、（通過excpt_info訪問）將包含多個指向etype_info（擴(kuò)展了type_info，這個名字是我啟的）的指針，它們分別指向了各個基類的etype_info。這樣，處理程序就可以把catch塊的參數(shù)和所有這些type_info比較，只要有一個相同，就調(diào)用catch塊。在結(jié)束這一部分之前，還有最后一個問題：異常處理程序是怎么知道異常和excpt_info結(jié)構(gòu)的？下面我就要回答這個問題。 VC+會把throw語句翻譯成下面的樣子： /throw E(; /編譯器會為E生成excpt_info結(jié)構(gòu) E e = E(; /在棧上創(chuàng)建異常 _CxxThrowException(&e, E

26、_EXCPT_INFO_ADDR;_CxxThrowException會把控制權(quán)連帶它的兩個參數(shù)都交給操作系統(tǒng)（控制權(quán)轉(zhuǎn)移是通過軟件中斷實現(xiàn)的，請參見RaiseException）。而操作系統(tǒng)，在為調(diào)用異?；卣{(diào)函數(shù)做準(zhǔn)備時，會把這兩個參數(shù)打包到一個_EXCEPTION_RECORD結(jié)構(gòu)中。接著，它從EXCEPTION_REGISTRATION鏈表的頭結(jié)點（由FS:0指向）開始，依次調(diào)用各節(jié)點的異常處理程序。而且，指向當(dāng)前EXCEPTION_REGISTRATION結(jié)構(gòu)的指針也會作為異常處理程序的第二個參數(shù)出現(xiàn)。前面已經(jīng)說過，VC+中的每個函數(shù)都在棧上創(chuàng)建并注冊了EXCEPTION_REGIST

27、RATION結(jié)構(gòu)。所以傳遞這個參數(shù)可以讓處理程序知道很多重要信息，比如說：EXCEPTION_REGISTRATION的id字段（用于查找catch塊）、函數(shù)的棧楨（用于清理棧楨）和EXCEPTION_REGISTRATION結(jié)點在異常鏈表中的位置（用于堆棧展開）等。第一個參數(shù)是指向_EXCEPTION_RECORD結(jié)構(gòu)的指針，通過它可以找到異常和它的excpt_info結(jié)構(gòu)。下面是excpt.h中定義的異?；卣{(diào)函數(shù)的原型： EXCEPTION_DISPOSITION (*handler( _EXCEPTION_RECORD* ExcRecord, void* EstablisherFrame

28、, _CONTEXT *ContextRecord, void* DispatcherContext;后兩個參數(shù)和我們的討論關(guān)系不大。函數(shù)的返回值是一個枚舉類型（也在excpt.h中定義），我前面已經(jīng)說過，如果處理程序找不到catch塊，它就會向系統(tǒng)返回ExceptionContinueSearch，對本文而言，我們只要知道這一個返回值就行了。_EXCEPTION_RECORD結(jié)構(gòu)是在winnt.h中定義的： struct _EXCEPTION_RECORD DWORD ExceptionCode; DWORD ExceptionFlags; _EXCEPTION_RECORD* ExcRec

29、ord; PVOID ExceptionAddress; DWORD NumberParameters; DWORD ExceptionInformation15; EXCEPTION_RECORD; ExceptionInformation數(shù)組中元素的個數(shù)和類型取決于ExceptionCode字段。如果是C+異常（異常代碼是0xe06d7363，源于throw語句），那么數(shù)組中將包含指向異常和excpt_info結(jié)構(gòu)的指針；如果是其他異常，那數(shù)組中基本上就不會有什么內(nèi)容，這些異常包括除零溢出、訪問違例等，你可以在winnt.h中找到它們的異常代碼。ExceptionFlags字段用于告訴異常

30、處理程序應(yīng)該采取什么操作。如果它是EH_UNWINDING（見Except.inc），那是說堆棧正在展開，這時，處理程序要清理棧楨，然后返回。否則處理程序應(yīng)該在函數(shù)中查找catch塊并調(diào)用它。清理棧楨意味著必須找到異常發(fā)生時生存在棧楨上的所有局部對象,并調(diào)用其析構(gòu)函數(shù)，下一節(jié)我們將就此進(jìn)行詳細(xì)討論。清理棧楨C+標(biāo)準(zhǔn)明確指出：堆棧展開工作必須調(diào)用異常發(fā)生時所有生存的局部對象的析構(gòu)函數(shù)。如下面的代碼： int g_i = 0; void foo( T o1, o2; T o3; 10/g_i; /這里會發(fā)生異常 T o4; /. foo有o1、o2、o3、o4四個局部對象，但異常發(fā)生時，o3已經(jīng)“

31、死亡”，o4還未“出生”，所以異常處理程序應(yīng)該只調(diào)用o1和o2的析構(gòu)函數(shù)。前面已經(jīng)說過，編譯器會在函數(shù)的很多地方安插代碼來記錄當(dāng)前的運行狀態(tài)。實際上，編譯器在函數(shù)中設(shè)置了一些關(guān)鍵區(qū)域，并為它們分配了id，進(jìn)入關(guān)鍵區(qū)域時要記錄它的id，退出時恢復(fù)前一個id。try塊就是一個例子,其id就是start id。所以，在try塊的入口，編譯器會把它的start id記到棧楨上去。局部對象從創(chuàng)建到銷毀也確定了一個關(guān)鍵區(qū)域，或者，換句話說，編譯器給每個局部對象分配了唯一的id，例如下面的程序： void foo( T t1; /. 編譯器會在t1的定義后面（也就是t1創(chuàng)建以后）,把它的id寫到棧楨上： v

32、oid foo( T t1; _id = t1_id; /編譯器插入的語句 /. 上面的_id是編譯器偷偷創(chuàng)建的局部變量，它的位置與EXCEPTION_REGISTRATION的id字段重疊。類似的，在調(diào)用對象的析構(gòu)函數(shù)前，編譯器會恢復(fù)前一個關(guān)鍵區(qū)域的id。清理棧楨時，異常處理程序讀出id的值（通過EXCEPTION_REGISTRATION結(jié)構(gòu)的id字段或棧楨指針EBP下面的4個字節(jié)來訪問）。這個id可以表明，函數(shù)在運行到與它相關(guān)聯(lián)的那個點之前沒有發(fā)生異常。所有在這一點之前定義的對象都已初始化，應(yīng)該調(diào)用這些對象中的一部分或全部對象的析構(gòu)函數(shù)。請注意某些對象是屬于子塊（如前面代碼中的o3）的，

33、發(fā)生異常時可能已經(jīng)銷毀了，不應(yīng)該調(diào)用它們的析構(gòu)函數(shù)。編譯器還為函數(shù)生成了另一個數(shù)據(jù)結(jié)構(gòu)堆棧展開表（unwindtable，我啟的名字），它是一個unwind結(jié)構(gòu)的數(shù)組，可通過funcinfo來訪問，如圖4所示。函數(shù)的每個關(guān)鍵區(qū)域都有一個unwind結(jié)構(gòu)，這些結(jié)構(gòu)在展開表中出現(xiàn)的次序和它們所對應(yīng)的區(qū)域在函數(shù)中的出現(xiàn)次序完全相同。一般unwind結(jié)構(gòu)也會關(guān)聯(lián)一個對象（別忘了，每個對象的定義都開辟了關(guān)鍵區(qū)域，并有id與其對應(yīng)），它里面有如何銷毀這個對象的信息。每當(dāng)編譯器碰到對象定義，它就生成一小段代碼，這段代碼知道對象在棧楨上的地址（就是它相對于棧楨指針的偏移），并能銷毀它。unwind結(jié)構(gòu)中有一個

34、字段用于保存這段代碼的入口地址： typedef void (*CLEANUP_FUNC(; struct unwind int prev; CLEANUP_FUNC cf; ; try塊對應(yīng)的unwind結(jié)構(gòu)的cf字段是空值NULL，因為沒有與它對應(yīng)的對象，所以也沒有東西需要它去銷毀。通過prev字段，這些unwind結(jié)構(gòu)也形成了一個鏈表。異常處理程序清理棧楨時，會讀取當(dāng)前的id值，以它為索引取得展開表中對應(yīng)的項，并調(diào)用其第二個字段指向的清理代碼，這樣，那個與之關(guān)聯(lián)的對象就被銷毀了。然后，處理程序?qū)⒁援?dāng)前unwind結(jié)構(gòu)的prev字段為索引，繼續(xù)在展開表中找下一個unwind結(jié)構(gòu)，調(diào)用其清理

35、代碼。這一過程將一直重復(fù)，直到鏈表的結(jié)尾（prev的值是-1）。圖6畫出了本節(jié)開始時提到的那段代碼的堆棧展開表。 現(xiàn)在把new運算符也加進(jìn)來，對于下面的代碼： T* p = new T(; 系統(tǒng)會首先為T分配內(nèi)存，然后調(diào)用它的構(gòu)造函數(shù)。所以，如果構(gòu)造函數(shù)拋出了異常，系統(tǒng)就必須釋放這些內(nèi)存。因此，動態(tài)創(chuàng)建那些擁有“有為的構(gòu)造函數(shù)”的類型時，VC+也為new運算符分配了id，并且堆棧展開表中也有與其對應(yīng)的項，其清理代碼將釋放分配的內(nèi)存空間。調(diào)用構(gòu)造函數(shù)前，編譯器把new運算符的id存到EXCEPTION_REGISTRATION結(jié)構(gòu)中，構(gòu)造函數(shù)順利返回后，它再把id恢復(fù)成原來的值。更進(jìn)一步說，構(gòu)造

36、函數(shù)拋出異常時，對象可能剛剛構(gòu)造了一部分，如果它有子成員對象或子基類對象，并且發(fā)生異常時它們中的一部分已經(jīng)構(gòu)造完成的話，就必須調(diào)用這些對象的析構(gòu)函數(shù)。和普通函數(shù)一樣，編譯器也給構(gòu)造函數(shù)生成了相關(guān)的數(shù)據(jù)來幫助完成這個任務(wù)。展開堆棧時，異常處理程序調(diào)用的是用戶定義的析構(gòu)函數(shù)，這一點你必須注意，因為它也有可能拋出異常！C+標(biāo)準(zhǔn)規(guī)定堆棧展開過程中，析構(gòu)函數(shù)不能拋出異常，否則系統(tǒng)將調(diào)用std:terminate。 實現(xiàn)本節(jié)我們討論其他三個有待詳細(xì)解釋的問題： a如何安裝異常處理程序 bcatch塊重新拋出異?；驋伋鲂庐惓r應(yīng)該如何處理 c如何對所有線程提供異常處理支持 隨同本文，有一個演示項目，查看其中

37、的文件可以得到一些編譯方面的幫助。 第一項任務(wù)是安裝異常處理程序，也就是把VC+的處理程序替換掉。從前面的討論中，我們已經(jīng)清楚地知道_CxxFrameHandler函數(shù)是VC+所有異常處理工作的入口。編譯器為每個函數(shù)都生成一段代碼，它們在發(fā)生異常時被調(diào)用，把相應(yīng)的funcinfo結(jié)構(gòu)的指針交給_CxxFrameHandler。 install_my_handler(函數(shù)會改寫_CxxFrameHandler的入口處的代碼，讓程序跳轉(zhuǎn)到my_exc_handler(函數(shù)。不過，_CxxFrameHandler位于只讀的內(nèi)存頁，對它的任何寫操作都會導(dǎo)致訪問違例，所以必須首先用VirtualProt

38、ectEx把該內(nèi)存頁的保護(hù)方式改成可讀寫，等改寫完畢后，再改回只讀。寫入的數(shù)據(jù)是一個jmp_instr結(jié)構(gòu)。/install_my_handler.cpp #include #include "install_my_handler.h" /C+默認(rèn)的異常處理程序 extern "C" EXCEPTION_DISPOSITION _CxxFrameHandler( struct _EXCEPTION_RECORD* ExceptionRecord, void* EstablisherFrame, struct _CONTEXT* ContextRecord

39、, void* DispatcherContext ; namespace char cpp_handler_instructions5; bool saved_handler_instructions = false; namespace my_handler /我的異常處理程序 EXCEPTION_DISPOSITION my_exc_handler( struct _EXCEPTION_RECORD *ExceptionRecord, void * EstablisherFrame, struct _CONTEXT *ContextRecord, void * DispatcherCon

40、text   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+size的頁面的保護(hù)方式改成可讀寫 DWORD old_protection; BOOL ret = VirtualProtectEx(hProcess, loc, si

41、ze, 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(void* loc, void* buffer, DWORD size HANDLE hProces

42、s = 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.jmp

43、 = 0xE9; /從_CxxFrameHandler+5開始計算偏移，因為jmp指令長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 Wr

44、iteMemory(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)中填充任何用于對齊的

45、空間。沒有這條指令，jmp_instr的大小將是8字節(jié)，而我們需要它是5字節(jié)。現(xiàn)在重新回到異常處理這個主題上來。調(diào)用catch塊時，它可能重新拋出異常或拋出新異常。前一種情況下，異常處理程序必須繼續(xù)傳播（propagate）當(dāng)前異常；后一種情況下，它需要在繼續(xù)之前銷毀原來的異常。此時，處理程序要面對兩個難題：“如何知道異常是源于catch塊還是程序的其他部分”和“如何跟蹤原來的異常”。我的解決方法是：在調(diào)用catch塊之前，把當(dāng)前異常保存在exception_storage對象中，并注冊一個專用于catch塊的異常處理程序catch_block_protector。調(diào)用get_exceptio

46、n_storage(函數(shù)，就能得到exception_storage對象： exception_storage* p = get_exception_storage(; p->set(pexc, pexc_info; 注冊 catch_block_protector; 調(diào)用catch塊; /.這樣，當(dāng)catch塊（重新）拋出異常時，程序?qū)?zhí)行catch_block_protector。如果是拋出了新異常，這個函數(shù)可以從exception_storage對象中分離出前一個異常并銷毀它；如果是重新拋出原來的異常（可以通過ExceptionInformation數(shù)組的前兩個元素知道是新異常還

47、是舊異常，后一種情況下著兩個元素都是0，參見下面的代碼），就通過拷貝ExceptionInformation數(shù)組來繼續(xù)傳播它。下面的代碼就是catch_block_protector(函數(shù)的實現(xiàn)。/- / 如果這個處理程序被調(diào)用了，可以斷定是catch塊（重新）拋出了異常。 / 異常處理程序（my_handler）在調(diào)用catch塊之前注冊了它。其任務(wù)是判斷 / catch塊拋出了新異常還是重新拋出了原來的異常，并采取相應(yīng)的操作。 / 在前一種情況下，它需要銷毀傳遞給catch塊的前一個異常對象；在后一種 / 情況下，它必須找到原來的異常并將其保存到ExceptionRecord中供異常 /

48、處理程序使用。 /- EXCEPTION_DISPOSITION catch_block_protector( _EXCEPTION_RECORD* ExceptionRecord, void* EstablisherFrame, struct _CONTEXT *ContextRecord, void* DispatcherContext throw ( EXCEPTION_REGISTRATION *pFrame; pFrame= reinterpret_cast(EstablisherFrame; if(!(ExceptionRecord->ExceptionFlags &

49、 (_EXCEPTION_UNWINDING | _EXCEPTION_EXIT_UNWIND void *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 = Exceptio

50、nRecord->ExceptionCode = MS_CPP_EXC; get_exception(ExceptionRecord, &pcur_exc; get_excpt_info(ExceptionRecord, &pexc_info; if(cpp_exc && 0 = pcur_exc && 0 = pexc_info /重新拋出 ExceptionRecord->ExceptionInformation1 = reinterpret_cast(pprev_exc; ExceptionRecord->Exceptio

51、nInformation2 = reinterpret_cast(pprev_excinfo; else exception_helper:destroy(pprev_exc, pprev_excinfo; return ExceptionContinueSearch; 下面是get_exception_storage(函數(shù)的一個實現(xiàn)： exception_storage* get_exception_storage(    static exception_storage es;    return &es;在單線程程序中，

52、這是一個完美的實現(xiàn)。但在多線程中，這就是個災(zāi)難了，想象一下多個線程訪問它，并把異常對象保存在里面的情景吧。由于每個線程都有自己的堆棧和異常處理鏈，我們需要一個線程安全的get_exception_storage實現(xiàn)：每個線程都有自己單獨的exception_storage，它在線程啟動時被創(chuàng)建，并在結(jié)束時被銷毀。Windows提供的線程局部存儲（thread local storage，TLS）可以滿足這個要求，它能讓每個線程通過一個全局鍵值來訪問為這個線程所私有的對象副本，這是通過TlsGetValue(和TlsSetValue這兩個API來完成的。中給出了get_exception_sto

53、rage(函數(shù)的實現(xiàn)。它會被編譯成動態(tài)鏈接庫，因為我們可以籍此知道線程的創(chuàng)建和退出系統(tǒng)在這兩種情況下都會調(diào)用所有（當(dāng)前進(jìn)程加載的）dll的DllMain(函數(shù)，這讓我們有機(jī)會創(chuàng)建特定于線程的數(shù)據(jù)，也就是exception_storage對象。 #include "excptstorage.h"#include namespace    DWORD dwstorage;namespace my_handler    _declspec(dllexport exception_storage* get_exception_storage( throw (            void * p = TlsGetValue(dwstorage;        return reinterpret_cast (p;    BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved &#