什麼更好/更快？嘗試趕上或避免異常？

我想知道，在一般編程中哪些更好或更快？避免發生異常或等待異常？什麼更好/更快？嘗試趕上或避免異常？

避免的例外是：

string a = null; 
list = someMethod(); 
if(list.Length > 0){ 
    a = list[0]; 
} 
if(a!=null) ...

或者嘗試catch異常......

string a = null; 
try{ 
    a = someMethod()[0]; 
catch{} 
if(a!=null) ...

來源

2011-01-07 carlosdubusm

取消單詞「更快」，這是無關緊要的。這甚至不是正確的使用try-catch的方式，因爲你是在拖動CLR。 – BoltClock 2011-01-07 17:24:55

只是一個例子... – carlosdubusm 2011-01-07 17:26:24

@BoltClock，不，它不是。如果發生異常。速度較慢。 – CaffGeek 2011-01-07 17:28:29

表現不是這裏最相關的關注點。問題是，兩者中的哪一個導致更易讀/可維護/可測試的程序。您可以稍後擔心性能。

一般來說，不要使用例外進行流量控制。它們實際上是非本地的goto，這使得程序更難以閱讀和遵循。因此，它們應該保留用於特殊情況。如果您不能使用try-catch塊進行流量控制，請不要。您的程序將更具可讀性和可維護性。

「正確」的方式來處理這種情況是

var list = someMethod(); 
if(list == null || list.Length == 0) { 
    // handle something bad 
} 
string a = list[0]; 
if(a != null) { 
    // go 
}

可以避開檢查list不爲空或不爲空，如果有，保證從someMethod返回的值是一個合同（Contract.Ensures）不爲空，不爲空。

但的確，例外情況在當地非常昂貴。無論它們是否會影響程序的性能（即瓶頸），都是另一個問題。但是正確使用，例外通常不是瓶頸（當應用程序崩潰時誰關心性能？）

來源

2011-01-07 17:28:11 jason

始終始終始終如果你能避免異常。

例外情況應該是例外。

如果您可以預測它，請防止它發生。

誰使用空的catch塊這樣的人應該使用一臺計算機被禁止......

它也快不進入catch塊。

來源

2011-01-07 17:24:52 CaffGeek

異常昂貴 - 如果您可以測試並避免異常，請這樣做。

異常不應用於正常的程序流程。

來源

2011-01-07 17:25:07 Oded

投擲異常是一個昂貴的任務，所以我會一直嘗試和驗證，而不是抓住。

這應該很容易進行測試，生成一些代碼，通過每次運行引發異常，並根據執行條件檢查和度量性能的類似代碼進行測試。

如果代碼記錄了哪些條件異常將被拋出的詳細信息，則應該能夠調整您的調用代碼。當然，你不能處理每個場景（可能是更低級別的運行時錯誤？），所以你的代碼只能真正嘗試並處理可能實際反應並可能繼續的異常。

來源

2011-01-07 17:25:13

這取決於。我幾乎總是儘量避免這種異常，除非這樣做成本過高。

來源

2011-01-07 17:25:45 Matthew

異常只能用於特殊情況（除非沒有其他選擇），所以當出現非常不尋常的事情時，您應該只使用try/catch，您仍然需要處理（彈出錯誤消息）。

try/catch也告訴程序員一些外部錯誤可能發生並需要處理。在你的例子中，list爲null只是程序執行/控制流程的一個正常部分，所以沒有什麼特殊之處。

此外，一個空的catch-all通常是一件壞事情（雖然有限的情況下，它需要）。無論如何，它肯定需要評論才能解釋爲什麼你沒有對異常做任何事情。

有一個useful blog post約棘手的例外可能對您有用

來源

2011-01-07 17:25:46 thecoop

單純從數量的指令/性能的角度來看在顯著ñ運行，避免了更貴，因爲你每次檢查的長度爲每個輸入。除了例外情況，catch分支僅在該可能情況下執行。

來源

2011-01-07 17:25:46 Aphex

當然避免異常，嘗試catch會導致損失性能。

來源

2011-01-07 17:28:24 styshoo

什麼更好/更快？嘗試趕上或避免異常？

回答

相關問題