自從開始考慮程式碼的執行效率和效能以後，寫程式碼考慮的東西越來越多了，比如什麼時候應該加try/catch？加太多的try/catch會不會降低效能？今天就來分享一下對try/catch對效能影響的一些看法。下面先來看三個問題：
問題一:當一段程式碼被try塊包圍後與不加try時在沒有異常發生的情況下,執行過程是否有區別?
問題一的回答:
1、 try{ }部分和不加try/catch語句塊的效率幾乎一樣, catch{}部分似乎需要100倍以上的時間 ,所以只要不把try{}catch{}作為你的程式的邏輯,這種設計就是合理的.
2、從我的經驗看來，在 try 中的程式碼和在沒有 try 的情況下的效率是一樣的，沒有影響。
問題二: 如果有區別,那麼這樣的區別對效能的影響有多大呢?
問題二的回答:
1、當同一型別的異常被第一次丟擲的時候，明顯可以感到效率的降低；但其後再丟擲就沒什麼感覺了。還是什麼文章中看到過這樣的說法：CLR的異常處理機制相比C++要高效很多。
2、就我學到的編譯知識，感覺TRY CATCH會小小影響編譯的速度，因為翻譯模式內要回填異常的處理地址，而在執行期間應該不會影響速度
3、沒什麼大的影響，對現在的機器配置來說，這點影響微不足道
4、對效率的影響不大，可以放心使用。因為就算你不寫程式碼去捕獲可能出現的異常，.net Framework在執行時也會幫你捕獲執行時出現的異常，轉向其異常處理程式，結果就是彈出對話方塊來提示你，我想大家在除錯的時候都見識過吧。
問題三: try的程式碼究竟做了些什麼?他對程式碼做的是每次執行時監視還是以類似中斷的的方式,當出現異常時主動呼叫什麼過程轉向異常處理.?
問題三的回答:
1、從硬體角度講，異常和中斷是同樣的機理，都是在滿足一定的條件的時候，由軟體和硬體觸發，並通過向量轉到相應的處理程式。因此，異常在沒有被觸發的時候，應該是不會對效能造成影響的。
另外，.net在產生異常時是逐步向外層查詢處理程式的，就是說，如果當前函式中沒有對異常進行處理，才查詢呼叫當前函式的那一個函式，一直找遍整個應用程式，如果還沒有，就交給runtime,在這種情況下，效率才是最低的，而且比較難於處理。
2、如果發生了異常,我認為捕獲的越早效率越高,但往往我們需要在一個合適的層面上來捕捉,所以有一個平衡問題,還是得具體問題具體分析.
3、個人覺得try catch語句是偵測語句。
try { 需要偵測語句 } catch(跟蹤錯誤類) { 錯誤操作語句 }
try偵測語句執行情況:
1、 當偵測語句執行出錯時,丟擲錯誤類,然後根據錯誤類提供的資訊,執行錯誤操作語句.
2、使用try catch語句效率低下我覺得有幾個原因,首先由於程式需要進行錯誤偵測,那麼執行偵測語句時需要更多的資源,其次,錯誤操作語句也要消耗相應的資源.
我的總結:
.net在產生異常時是逐步向外層查詢處理程式的,因此可以說捕獲的越早效率越高.如果當前應用程式沒有對異常進行處理，那麼當捕獲到異常時就會一層一層向外查詢，如果沒有查詢到異常處理程式，就交給runtime,在這種情況下，效率才是最低的，而且比較難於處理。
對於效能上的開銷,按照以上的資訊基本可以忽略,因為"就算你不寫程式碼去捕獲可能出現的異常，.net Framework在執行時也會幫你捕獲執行時出現的異常，轉向其異常處理程式...".所以只要你的catch是用來捕獲的不可預知的異常應該就不會有額外的開銷.
新的疑問:異常交給runtime進行處理效率才是最低的?
經驗告訴我似乎即使程式不出現異常時似乎加了try catch的還是要稍慢,個人認為不加try catch時程式碼的執行速度應該比較快.
猜測:我想編譯時在哪個層次上有異常處理應該是被標記了的.該層以下一旦有catch型別異常就跳轉到catch塊.從而也影響了最終編譯程式的大小.
歡迎大家一起探討!