很多帖子都分析過Try-Catch的機制，以及其對性能的影響。

但是并沒有證據證明，Try-Catch過于損耗了系統的性能，尤其是在托管環境下。記得園子里有位網友使用StopWatch分析過Try-Catch在不同情況下，與無Try-Catch的代碼相比，代碼運行的時間指標，結果并沒有很大差異。

下面我來結合IL分析一下Try-Catch吧。

● 機制分析

 .Net 中基本的異常捕獲與處理機制是由try…catch…finally塊來完成的，它們分別完成了異常的監測、捕獲與處理工作。一個try塊可以對應零個或多個catch塊，可以對應零個或一個finally塊。不過沒有catch的try似乎沒有什么意義，如果try對應了多個catch，那么監測到異常后，CLR會自上而下搜索catch塊的代碼，并通過異常過濾器篩選對應的異常，如果沒有找到，那么CLR將沿著調用堆棧，向更高層搜索匹配的異常，如果已到堆棧頂部依然沒有找到對應的異常，就會拋出未處理的異常了，這時catch塊中的代碼并不會被執行。所以距離try最近的catch塊將最先被遍歷到。

如有以下代碼：

對應IL如下：

末尾的幾行代碼揭示出IL是怎樣處理異常處理的。最后三行的每一個Item被稱作Exception Handing Clause，EHC組成Exception Handing Table，EHT與正常代碼之間由ret返回指令隔開。

    可以看出，FormatException排列在EHT的第一位。

    當代碼成功執行或反之而返回后，CLR會遍歷EHT：

    1. 如果拋出異常， CLR會根據拋出異常的代碼的“地址”找到對應的EHC（IL_0001 to IL_0010為檢測代碼的范圍），這個例子中CLR將找到2條EHC，FormatException會最先被遍歷到，且為適合的EHC。

    2. 如果返回的代碼地址在IL_0001 to IL_0029內，那么還會執行finally handler 即IL_0029 to IL_0033中的代碼，不管是否因成功執行代碼而返回。

    事實上，catch與finally的遍歷工作是分開進行的，如上文所言，CLR首先做的是遍歷catch，當找到合適的catch塊后，再遍歷與之對應finally；而且這個過程會遞歸進行至少兩次，因為編譯器將C#的try…catch…finally翻譯成IL中的兩層嵌套。

當然如果沒有找到對應的catch塊，那么CLR會直接執行finally，然后立即中斷所有線程。Finally塊中的代碼肯定會被執行，無論try是否檢測到了異常。

改進建議

    由上面的內容可以得出：

    如果使用了“Try-Catch”，且捕獲到了異常，CLR做的只不過是遍歷Exception Handing Table中的Catch項；然后再次遍歷Exception Handing Table中的Finally項，所用時間幾乎都花費在遍歷Exception Handing Table上；而如果沒有捕獲到異常，CLR只是遍歷Exception Handing Table中的Finally項，所需時間微乎其微。

    而“Try-Catch”遍歷后的執行對應操作所用時間，則根據你的具體代碼所定，“Try-Catch”引起的只是監控與觸發，不應將這部分的代碼時間也算“Try-Catch”的消耗。

    所以，可以從性能和代碼評審兩方面考慮，一般建議有以下幾點準則：

    1.盡量給CLR一個明確的異常信息，不要使用Exception去過濾異常

    2.盡量不要將try…catch寫在循環中

    3. try盡量少的代碼，如果有必要可以使用多個catch塊，并且將最有可能拋出的異常類型，書寫在距離try最近的位置

    4.不要只聲明一個Exception對象，而不去處理它。這樣做白白增加了Exception Handing Table的長度。

    5.使用性能計數器實用工具的“CLR Exceptions”檢測異常情況，并適當優化

    6.使用成員的Try-Parse模式，如果拋出異常，那么用false代替它

    結論，Try-Catch雖然會消費一點時間，但程序人員大可不必談虎色變，通過上面的分析，與其說“Try-Catch”會損耗或影響性能，不如說“Try-Catch”與其他代碼一樣，只是性能的普通消費者，但出于代碼書寫評審方面的考慮，還是盡量關照一下“Try-Catch”吧。