try-catch會影響程式效能嗎

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代替它 

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

🎜