Try-Catch真的會影響程式效能嗎
今天和TL爭論try-catch使用上的問題，是否為了程式碼看上去的美觀而把該方法下得所有程式碼都放到try-catch中，我理所當然的持反對意見，但對try-catch的實現機制沒有深入研究過，不能說出有說服力的理由，今天在網上找到個.net的try-catch分析，和大家分享下
很多帖子都分析過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區塊將最先被遍歷到。
如有下列程式碼：
try
{
Convert.ToInt32("Try") 🎠 {
string CatchFormatException = "CatchFormatException";
}
c CatchNullReferenceException = "CatchNullReferenceException";
}
finally
{
private hidebysig instance void Form1_Load(object sender,
class [mscorlib]System.EventArgs e) cil managed
{
// Code size 53 (0x35)
.maxstack 1
.locals init ([0] class [mscorlib]System.FormatException ex1,
. NullReferenceException ex2,
[3] string CatchNullReferenceException,
[4] string Finally)
IL_0000: nop
IL_0001: nop
. ]System.Convert::ToInt32(string)
IL_000c: pop
IL_000d: nop
IL_000e: leave.s IL_0026
IL_0010: stloc.0
IL_0011: nop
: stloc.0
IL
IL_0018: nop
IL_0019: leave.s IL_0026
IL_001b : stloc.2
IL_001c: nop
IL_001d: ldstr "CatchNullReferenceException"
IL_0022: stloc.3
IL_0023: nop
IL_0027: leave.s IL_0033
IL_0029: nop
IL_002a: ldstr "Finally"
IL_002f: stloc.s Finally
IL_0031: nop
IL_0032: endfinally
IL_0033: nop
IL_0034: .try IL_0001 to IL_0010 catch [mscorlib]System.FormatException handler IL_0010 to IL_001b
.try IL_0001 to IL_0010 catch [mscorlib]System.NullReferenceException handler IL_001b to IL_0026
.try IL_0001 to IL_0029 Form1::Form1_Load
末端的幾行程式碼揭示出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所做的只不過是遍歷中的Catch項；然後再次遍歷中的Catch項；然後再次遍歷中的Finally項，所用時間幾乎都花在遍歷Exception Handing Table上；而如果沒有捕獲到異常，CLR只是遍歷Exception Handing Table中的Finally項，所需時間微乎其微。
而「Try-Catch」遍歷後的執行對應操作所用時間，則根據你的具體程式碼所定，「Try-Catch」所造成的只是監控與觸發，不應將這部分的程式碼時間也算「Try-Catch ”的消耗。
所以，可以從效能和程式碼評審兩方面考慮，一般建議有以下幾點準則：
1.盡量給CLR一個明確的異常訊息，不要使用Exception去過濾異常
2.盡量給CLR一個明確的異常訊息，不要使用Exception去過濾異常
2.盡量使用循環中
3. try盡量少的程式碼，如果有必要可以使用多個catch塊，並且將最有可能拋出的異常類型，書寫在距離try最近的位置
4.不要聲明一個Exception對象，而不去處理它。這樣做白白增加了Exception Handing Table的長度。
5.使用性能計數器實用工具的「CLR Exceptions」檢測異常情況，並適當優化
6.使用成員的Try-Parse模式，如果拋出異常，那麼用false代替它
