coding try catch規範

如果使用了“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”吧。