方法定義或調用中的異常處理？

我想知道是否有合適的地方來處理異常。我應該在我的方法中處理它，還是應該在方法調用中處理它？或者它有什麼關係？方法定義或調用中的異常處理？

對不起，但我找不到任何關於此（谷歌搜索「異常處理範圍」沒有返回我正在尋找）。

實施例：

// this way... 
void readFile(string file) 
{ 
    try 
    { 
     /* do my stuff */ 
    } 
    catch(Exception exception) 
    { 
     /* handle exception */ 
    } 
} 

int main() 
{ 
    readFile(file); 
} 

// or this way? 
void readFile(string file) 
{ 
    /* do my stuff */ 
} 

int main() 
{ 
    try 
    { 
     readFile(file); 
    } 
    catch(Exception exception) 
    { 
     /* handle exception */ 
    } 
}

預先感謝。

來源

2011-11-16 efermat

人們請停止回答這個大量的重複。 –

我很抱歉，但正如我所說，我找不到任何回答我的問題的東西。我很感激，如果你可以張貼鏈接重複，甚至告訴我一些'搜索條件'。 – efermat

@John：如果是重複的，請投票結束。 –

一般而言，您希望處理這樣做的錯誤。

如果在上面的示例中，您想嘗試讀取文件，如果該文件失敗，請閱讀默認文件，您可以像第一個示例中那樣處理它。

如果readFile操作失敗對main（）的其餘部分至關重要，那麼您需要將異常傳遞給它，以便它可以處理readFile（）失敗的任何後果，並且這將在第二次例。

當然，您可以隨時處理方法中的錯誤（或一些可能的例外），並重新拋出或讓某些通過或其他方式。

真的，雖然它的程序流程決定了你的異常處理的位置。在有意義的情況下處理異常。

來源

2011-11-16 18:15:26 Chris

最好的做法是讓上層處理異常。想象一下，你正在將你的底層文件閱讀器打包到一個庫中，並在那裏處理異常。您不會讓您的代碼的用戶有能力以他們所期望的方式處理異常。

來源

2011-11-16 18:13:34 Tudor

我知道Eric Lippert喜歡讓例外情況像現在一樣飆升到頂級水平，但我不同意。假設IDictionary.Add的實現調用了一個引發InvalidOperationException的方法。調用者可能期望捕獲InvalidOperationException，並認爲這樣的異常將意味着字典已經保存了密鑰，但是在其他情況下處於合法狀態。捕捉，包裝和重新拋出異常似乎是避免該問題的最佳方法。太糟糕了，現有的異常機制並不會特別方便。 – supercat

如果你可以處理異常，從它恢復並繼續，那麼你應該立即做到這一點。

另一方面，如果沒有什麼明智的做法可以處理異常，那麼最好的辦法就是讓異常在調用堆棧中傳播。最終，頂層代碼將被迫捕獲異常並將其記錄/顯示給用戶，否則應用程序將崩潰。

來源

2011-11-16 18:15:54

只有在您確實計劃在特定情況下做某件事情時才處理異常（例如，與DB交談併發生死鎖異常，您可能希望重試DB操作）。如果您只是想做一些通用的異常處理操作（例如記錄每個異常），請儘可能在最高級別（通常是UI）中執行此操作，並且不要將代碼與各處的異常處理程序混淆在一起 - 只要讓異常出現泡沫即可。

來源

2011-11-16 18:16:09

第一種方法通常比較好，因爲所有的文件都由readFile處理，調用readFile的代碼不必擔心文件處理問題。然而，你可以從readFile返回一個布爾值，告訴調用者操作是否成功：

bool readFile(string file) 
{ 
    try { 
     /* do my stuff */ 
     return true; 
    } catch(Exception exception) { 
     /* handle exception */ 
     return false; 
    } 
}

來源

2011-11-16 18:17:22

如果readFile的調用者想要對異常執行其他操作而不是您正在執行的操作，該怎麼辦？上面的代碼將無法訪問異常詳細信息。 – Tudor

如何將異常作爲「ref」或「out」參數傳遞？請注意，如果有人希望調用者在不必使用Pokemon異常異常處理的情況下進行恢復，那麼讓異常冒泡調用堆棧不是合理的選擇。必須要麼包裝並重新拋出異常，要麼必須通過其他方式讓調用者知道操作失敗的方式不會破壞系統的其他部分。如果調用者將要預測異常，將它作爲「ref」或「out」參數返回似乎比包裝和重新拋出它更好。 – supercat

你是對的，不同的方法是可能的。它總是取決於你想要做什麼。儘管如此，如果發現更容易處理不會拋出異常並限制問題而不是傳播它們的方法。 –

方法定義或調用中的異常處理？

回答

相關問題