woaidongmao

　　與傳統(tǒng)語言相比，C++的一項(xiàng)革命性創(chuàng)新就是它支持異常處理。傳統(tǒng)的錯(cuò)誤處理方式經(jīng)常滿足不了要求，而異常處理則是一個(gè)極好的替代解決方案。它將正常代碼和錯(cuò)誤處理代碼清晰的劃分開來，程序變得非常干凈并且容易維護(hù)。本文討論了編譯器如何實(shí)現(xiàn)異常處理。我將假定你已經(jīng)熟悉異常處理的語法和機(jī)制。本文還提供了一個(gè)用于VC++的異常處理庫，要用庫中的處理程序替換掉VC++提供的那個(gè)，你只需要調(diào)用下面這個(gè)函數(shù)：

　　之后，程序中的所有異常，從它們被拋出到堆棧展開（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é)構(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)注冊自己的異常處理程序。

　　注冊時(shí)，只需要?jiǎng)?chuàng)建這樣一個(gè)結(jié)構(gòu)，然后把它的地址放到FS段偏移0的位置上去就行了。下面這句匯編代碼演示了這一操作：
mov FS:[0], exc_regp

　　prev字段用于建立一個(gè)EXCEPTION_REGISTRATION結(jié)構(gòu)的鏈表，每次注冊新的EXCEPTION_REGISTRATION時(shí)，我們都要把原來注冊的那個(gè)的地址存到prev中。

　　那么，那個(gè)異常回調(diào)函數(shù)長什么樣呢？在excpt.h中，windows定義了它的原形：

　　不要管它的參數(shù)和返回值，我們先來看一個(gè)簡單的例子。下面的程序注冊了一個(gè)異常處理程序，然后通過除以零產(chǎn)生了一個(gè)異常。異常處理程序捕獲了它，打印了一條消息就完事大吉并退出了。

　　注意EXCEPTION_REGISTRATION必須定義在棧上，并且必須位于比上一個(gè)結(jié)點(diǎn)更低的內(nèi)存地址上，Windows對此有嚴(yán)格要求，達(dá)不到的話，它就會(huì)立刻終止進(jìn)程。

　　函數(shù)和堆棧

　　堆棧是用來保存局部對象的連續(xù)內(nèi)存區(qū)。更明確的說，每個(gè)函數(shù)都有一個(gè)相關(guān)的棧楨（stack frame）來保存它所有的局部對象和表達(dá)式計(jì)算過程中用到的臨時(shí)對象，至少理論上是這樣的。但現(xiàn)實(shí)中，編譯器經(jīng)常會(huì)把一些對象放到寄存器中以便能以更快的速度訪問。堆棧是一個(gè)處理器（CPU）層次的概念，為了操縱它，處理器提供了一些專用的寄存器和指令。

　　圖1是一個(gè)典型的堆棧，它示出了函數(shù)foo調(diào)用bar，bar又調(diào)用widget時(shí)的情景。請注意堆棧是向下增長的，這意味著新壓入的項(xiàng)的地址低于原有項(xiàng)的地址。

　　通常編譯器使用EBP寄存器來指示當(dāng)前活動(dòng)的棧楨。本例中，CPU正在運(yùn)行widget，所以圖中的EBP指向了widget的棧楨。編譯器在編譯時(shí)將所有局部對象解析成相對于棧楨指針（EBP）的固定偏移，函數(shù)則通過棧楨指針來間接訪問局部對象。舉個(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位處理器上）；類似的，push EBP的作用是把ESP減去4，然后將EBP的值放到ESP指向的位置中去。

　　編譯器編譯一個(gè)函數(shù)時(shí)，會(huì)在它的開頭添加一些代碼來為其創(chuàng)建并初始化棧楨，這些代碼被稱為序言（prologue）；同樣，它也會(huì)在函數(shù)的結(jié)尾處放上代碼來清除棧楨，這些代碼叫做尾聲（epilogue）。

　　一般情況下，序言是這樣的：

　　第一條指令把原來的棧楨指針EBP保存到棧上；第二條指令通過讓EBP指向主調(diào)函數(shù)的EBP的保存位置來激活被調(diào)函數(shù)的棧楨；第三條指令把ESP減去了一個(gè)數(shù)字，這樣ESP就指向了當(dāng)前棧楨的末尾，而這個(gè)數(shù)字是函數(shù)要用到的所有局部對象和臨時(shí)對象的大小。編譯時(shí)，編譯器知道函數(shù)的所有局部對象的類型和“體積”，所以，它能很容易的計(jì)算出棧楨的大小。

　　尾聲所做的正好和序言相反，它必須把當(dāng)前棧楨從棧上清除掉：

　　它讓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ì)先把緊隨在它后面的那條指令的地址（被調(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í)知道：

　　當(dāng)然，也可以把參數(shù)的總體積寫在被調(diào)函數(shù)的返回指令的后面，讓被調(diào)函數(shù)去移除參數(shù)，下面的指令就在返回主調(diào)函數(shù)前從棧中移去了24個(gè)字節(jié)：

　　取決于被調(diào)函數(shù)的調(diào)用約定（call convention），這兩種方式每次只能用一個(gè)。你還要注意的是每個(gè)線程都有自己獨(dú)立的堆棧。

　　C++和異常

　　回憶一下我在第一節(jié)中介紹的EXCEPTION_REGISTRATION結(jié)構(gòu)，我們曾用它向操作系統(tǒng)注冊了發(fā)生異常時(shí)要被調(diào)用的回調(diào)函數(shù)。VC++也是這么做的，不過它擴(kuò)展了這個(gè)結(jié)構(gòu)的語義，在它的后面添加了兩個(gè)新字段：

　　VC++會(huì)為絕大部分函數(shù)③添加一個(gè)EXCEPTION_REGISTRATION類型的局部變量，它的最后一個(gè)字段（ebp）與棧楨指針指向的位置重疊。函數(shù)的序言創(chuàng)建這個(gè)結(jié)構(gòu)并把它注冊給操作系統(tǒng)，尾聲則恢復(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é)構(gòu)看函數(shù)中有沒有catch塊對當(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í)生存在這些棧楨上的所有局部對象，并依次調(diào)用它們的析構(gòu)函數(shù)。后面我將對此進(jìn)行詳細(xì)介紹。

　　異常處理程序把這項(xiàng)工作委托給了各個(gè)棧楨自己的異常處理程序。從FS:[0]指向的異常處理鏈的第一個(gè)結(jié)點(diǎn)開始，它依次調(diào)用每個(gè)結(jié)點(diǎn)的處理程序，告訴它堆棧正在展開。與之相呼應(yīng)，這些處理程序會(huì)調(diào)用每個(gè)局部對象的析構(gòu)函數(shù)，然后返回。此過程一直進(jìn)行到與異常處理程序自身相對應(yīng)的那個(gè)結(jié)點(diǎn)為止。

　　由于catch塊是函數(shù)的一部分，所以它使用的也是函數(shù)的棧楨。因此，在調(diào)用catch塊之前，異常處理程序必須激活它所隸屬的函數(shù)的棧楨。

　　其次，每個(gè)catch塊都只接受一個(gè)參數(shù)，其類型是它希望捕獲的異常的類型。異常處理程序必須把異常對象本身或者是異常對象的引用拷貝到catch塊的棧楨上，編譯器在funcinfo中記錄了相關(guān)信息，處理程序根據(jù)這些信息就能知道到哪去拷貝異常對象了。

　　拷貝完異常并激活棧楨后，處理程序?qū)⒄{(diào)用catch塊。而catch塊將把控制權(quán)下一步要轉(zhuǎn)移到的地址返回來。請注意：雖然這時(shí)堆棧已經(jīng)展開，棧楨也都被清除了，但它們占據(jù)的內(nèi)存空間并沒有被覆蓋，所有的數(shù)據(jù)都還好好的待在棧上。這是因?yàn)楫惓Ｌ幚沓绦蛉栽趫?zhí)行，象其他函數(shù)一樣，它也需要棧來存放自己的局部對象，而其棧楨就位于發(fā)生異常的那個(gè)函數(shù)的棧楨的下面。catch塊返回以后，異常處理程序需要“殺掉”異常對象。此后，它讓ESP指向目標(biāo)函數(shù)（控制權(quán)要轉(zhuǎn)移到的那個(gè)函數(shù)）的棧楨的末尾——這樣就把（包括它自己的在內(nèi)的）所有棧楨都刪除了，然后再跳轉(zhuǎn)到catch塊返回的那個(gè)地址去，就勝利的完成整個(gè)異常處理任務(wù)了。但它怎么知道目標(biāo)函數(shù)的棧楨末尾在哪呢？事實(shí)上它沒法知道，所以編譯器把這個(gè)地址保存到了棧楨上（由前言來完成），如圖3所示，棧楨指針EBP下面第16個(gè)字節(jié)就是。

　　當(dāng)然，catch塊也可能拋出新異常，或者是將原來的異常重新拋出。處理程序必須對此有所準(zhǔn)備。如果是拋出新異常，它必須殺掉原來的那個(gè)；而如果是重新拋出原來的異常，它必須能繼續(xù)傳播（propagate）這個(gè)異常。

　　這里我要特別強(qiáng)調(diào)一點(diǎn)：由于每個(gè)線程有自己獨(dú)立的堆棧，所以每個(gè)線程也都有自己獨(dú)立的、由FS:[0]指向的EXCEPTION_REGISTRATION鏈。

　　C++和異常—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++給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塊表，看是否有對當(dāng)前異常感興趣的catch塊。在try塊發(fā)生嵌套時(shí)，異常將既源于內(nèi)層try塊，也源于外層try塊。這種情況下，處理程序應(yīng)該按先內(nèi)后外的順序查找catch塊。但它其實(shí)沒必要關(guān)心這些，因?yàn)椋?span lang="EN-US">try塊表中，VC++總是把內(nèi)層try塊放在外層try塊的前面。

　　異常處理程序還有一個(gè)難題就是“如何根據(jù)catch塊的相關(guān)數(shù)據(jù)結(jié)構(gòu)判斷這個(gè)catch塊是否愿意處理當(dāng)前異常”。這是通過比較異常的類型和catch塊的參數(shù)的類型來完成的。例如下面這個(gè)程序：

　　如果H和E的類型完全相同的話，catch塊就要捕獲這個(gè)異常。這意味著處理程序必須在運(yùn)行時(shí)進(jìn)行類型比較，對C等語言來說，這是不可能的,因?yàn)樗鼈儫o法在運(yùn)行時(shí)得到對象的類型。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_info是否相同，就能知道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)得到。由于異常處理程序需要拷貝異常對象（在調(diào)用catch塊之前），也需要消除掉它（在調(diào)用catch塊之后），所以編譯器在這個(gè)結(jié)構(gòu)中同時(shí)提供了異常的拷貝構(gòu)造函數(shù)、大小和析構(gòu)函數(shù)的信息。

　　在catch塊的參數(shù)是基類，而異常是派生類時(shí)，異常處理程序也應(yīng)該調(diào)用catch塊。然而，這種情況下，比較它們的type_info絕對是不相等，因?yàn)樗鼈儽緛砭筒皇窍嗤念愋汀６遥?span lang="EN-US">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塊的參數(shù)和所有這些type_info比較，只要有一個(gè)相同，就調(diào)用catch塊。

　　在結(jié)束這一部分之前，還有最后一個(gè)問題：異常處理程序是怎么知道異常和excpt_info結(jié)構(gòu)的？下面我就要回答這個(gè)問題。

　　VC++會(huì)把throw語句翻譯成下面的樣子：

　　__CxxThrowException會(huì)把控制權(quán)連帶它的兩個(gè)參數(shù)都交給操作系統(tǒng)（控制權(quán)轉(zhuǎn)移是通過軟件中斷實(shí)現(xiàn)的，請參見RaiseException）。而操作系統(tǒng)，在為調(diào)用異常回調(diào)函數(shù)做準(zhǔn)備時(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)建并注冊了EXCEPTION_REGISTRATION結(jié)構(gòu)。所以傳遞這個(gè)參數(shù)可以讓處理程序知道很多重要信息，比如說：EXCEPTION_REGISTRATION的id字段（用于查找catch塊）、函數(shù)的棧楨（用于清理?xiàng)E）和EXCEPTION_REGISTRATION結(jié)點(diǎn)在異常鏈表中的位置（用于堆棧展開）等。第一個(gè)參數(shù)是指向_EXCEPTION_RECORD結(jié)構(gòu)的指針，通過它可以找到異常和它的excpt_info結(jié)構(gòu)。下面是excpt.h中定義的異常回調(diào)函數(shù)的原型：

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

　　ExceptionInformation數(shù)組中元素的個(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í)生存在棧楨上的所有局部對象,并調(diào)用其析構(gòu)函數(shù)，下一節(jié)我們將就此進(jìn)行詳細(xì)討論。

　　清理?xiàng)E

　　 C++標(biāo)準(zhǔn)明確指出：堆棧展開工作必須調(diào)用異常發(fā)生時(shí)所有生存的局部對象的析構(gòu)函數(shù)。如下面的代碼：

　　foo有o1、o2、o3、o4四個(gè)局部對象，但異常發(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è)例子,其id就是start id。所以，在try塊的入口，編譯器會(huì)把它的start id記到棧楨上去。局部對象從創(chuàng)建到銷毀也確定了一個(gè)關(guān)鍵區(qū)域，或者，換句話說，編譯器給每個(gè)局部對象分配了唯一的id，例如下面的程序：

　　編譯器會(huì)在t1的定義后面（也就是t1創(chuàng)建以后）,把它的id寫到棧楨上：

　　上面的_id是編譯器偷偷創(chuàng)建的局部變量，它的位置與EXCEPTION_REGISTRATION的id字段重疊。類似的，在調(diào)用對象的析構(gòu)函數(shù)前，編譯器會(huì)恢復(fù)前一個(gè)關(guān)鍵區(qū)域的id。

　　清理?xiàng)E時(shí)，異常處理程序讀出id的值（通過EXCEPTION_REGISTRATION結(jié)構(gòu)的id字段或棧楨指針EBP下面的4個(gè)字節(jié)來訪問）。這個(gè)id可以表明，函數(shù)在運(yùn)行到與它相關(guān)聯(lián)的那個(gè)點(diǎn)之前沒有發(fā)生異常。所有在這一點(diǎn)之前定義的對象都已初始化，應(yīng)該調(diào)用這些對象中的一部分或全部對象的析構(gòu)函數(shù)。請注意某些對象是屬于子塊（如前面代碼中的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)的次序和它們所對應(yīng)的區(qū)域在函數(shù)中的出現(xiàn)次序完全相同。一般unwind結(jié)構(gòu)也會(huì)關(guān)聯(lián)一個(gè)對象（別忘了，每個(gè)對象的定義都開辟了關(guān)鍵區(qū)域，并有id與其對應(yīng)），它里面有如何銷毀這個(gè)對象的信息。每當(dāng)編譯器碰到對象定義，它就生成一小段代碼，這段代碼知道對象在棧楨上的地址（就是它相對于棧楨指針的偏移），并能銷毀它。unwind結(jié)構(gòu)中有一個(gè)字段用于保存這段代碼的入口地址：

　　try塊對應(yīng)的unwind結(jié)構(gòu)的cf字段是空值NULL，因?yàn)闆]有與它對應(yīng)的對象，所以也沒有東西需要它去銷毀。通過prev字段，這些unwind結(jié)構(gòu)也形成了一個(gè)鏈表。異常處理程序清理?xiàng)E時(shí)，會(huì)讀取當(dāng)前的id值，以它為索引取得展開表中對應(yīng)的項(xiàng)，并調(diào)用其第二個(gè)字段指向的清理代碼，這樣，那個(gè)與之關(guān)聯(lián)的對象就被銷毀了。然后，處理程序?qū)⒁援?dāng)前unwind結(jié)構(gòu)的prev字段為索引，繼續(xù)在展開表中找下一個(gè)unwind結(jié)構(gòu)，調(diào)用其清理代碼。這一過程將一直重復(fù)，直到鏈表的結(jié)尾（prev的值是-1）。圖6畫出了本節(jié)開始時(shí)提到的那段代碼的堆棧展開表。

　　現(xiàn)在把new運(yùn)算符也加進(jìn)來，對于下面的代碼： 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)造函數(shù)”的類型時(shí)，VC++也為new運(yùn)算符分配了id，并且堆棧展開表中也有與其對應(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í)，對象可能剛剛構(gòu)造了一部分，如果它有子成員對象或子基類對象，并且發(fā)生異常時(shí)它們中的一部分已經(jīng)構(gòu)造完成的話，就必須調(diào)用這些對象的析構(gòu)函數(shù)。和普通函數(shù)一樣，編譯器也給構(gòu)造函數(shù)生成了相關(guān)的數(shù)據(jù)來幫助完成這個(gè)任務(wù)。

　　展開堆棧時(shí)，異常處理程序調(diào)用的是用戶定義的析構(gòu)函數(shù)，這一點(diǎn)你必須注意，因?yàn)樗灿锌赡軖伋霎惓＃?span lang="EN-US">C++標(biāo)準(zhǔn)規(guī)定堆棧展開過程中，析構(gòu)函數(shù)不能拋出異常，否則系統(tǒng)將調(diào)用std::terminate。

　　實(shí)現(xiàn)

　　本節(jié)我們討論其他三個(gè)有待詳細(xì)解釋的問題：

　　a)如何安裝異常處理程序

　　b)catch塊重新拋出異常或拋出新異常時(shí)應(yīng)該如何處理

　　c)如何對所有線程提供異常處理支持

　　隨同本文，有一個(gè)演示項(xiàng)目，查看其中的readme.txt文件可以得到一些編譯方面的幫助。

　　第一項(xiàng)任務(wù)是安裝異常處理程序，也就是把VC++的處理程序替換掉。從前面的討論中，我們已經(jīng)清楚地知道__CxxFrameHandler函數(shù)是VC++所有異常處理工作的入口。編譯器為每個(gè)函數(shù)都生成一段代碼，它們在發(fā)生異常時(shí)被調(diào)用，把相應(yīng)的funcinfo結(jié)構(gòu)的指針交給__CxxFrameHandler。

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

　　編譯指令#pragma pack(push, 1)告訴編譯器不要在jmp_instr結(jié)構(gòu)中填充任何用于對齊的空間。沒有這條指令，jmp_instr的大小將是8字節(jié)，而我們需要它是5字節(jié)。

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

　　注冊 catch_block_protector;

　　調(diào)用catch塊; //....

　　這樣，當(dāng)catch塊（重新）拋出異常時(shí)，程序?qū)?huì)執(zhí)行catch_block_protector。如果是拋出了新異常，這個(gè)函數(shù)可以從exception_storage對象中分離出前一個(gè)異常并銷毀它；如果是重新拋出原來的異常（可以通過ExceptionInformation數(shù)組的前兩個(gè)元素知道是新異常還是舊異常，后一種情況下著兩個(gè)元素都是0，參見下面的代碼），就通過拷貝ExceptionInformation數(shù)組來繼續(xù)傳播它。下面的代碼就是catch_block_protector()函數(shù)的實(shí)現(xiàn)。

　　下面是get_exception_storage()函數(shù)的一個(gè)實(shí)現(xiàn)：

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

　　Excptstorage.cpp中給出了get_exception_storage()函數(shù)的實(shí)現(xiàn)。它會(huì)被編譯成動(dòng)態(tài)鏈接庫，因?yàn)槲覀兛梢约酥谰€程的創(chuàng)建和退出——系統(tǒng)在這兩種情況下都會(huì)調(diào)用所有（當(dāng)前進(jìn)程加載的）dll的DllMain()函數(shù)，這讓我們有機(jī)會(huì)創(chuàng)建特定于線程的數(shù)據(jù)，也就是exception_storage對象。

　　結(jié)論

　　綜上所述，異常處理是在操作系統(tǒng)的協(xié)助下，由C++編譯器和運(yùn)行時(shí)異常處理庫共同完成的。