捕獲最佳實踐的異常（c＃/ .net）

Question

如果我有這樣的代碼：

void a()
{
    try
    {
        b();
    }
    catch (MyException)
    {
        // Handle any problems that occurred in b(c(d()))
    }
}

void b()
{
    c();
    // Do something else
}

void c()
{
    d();
    // Do something else
}

void d()
{
    // Do something, throw a MyException if it fails
}

假設在任何時候都不需要清理，最好在c（）中調用d（）和在b（）中調用c（）時調用try {} catch {throw;}，還是認為OK讓d（）的異常在沒有任何介入的try / catch塊的情況下自然地冒泡到a（）“自然”？

我認為額外的try / catch塊可以作為一種“文檔”，但它們似乎是多余的，所以我只是想知道其他人會認為最好的方法。

對不起，如果這有點太基礎了，我試圖了解異常，但我似乎對它們沒有好感覺。

Answer 1

讓它傳播直到你可以處理它。 如果你無法處理它，就沒有必要抓住它。 所以問題是，你能否有效地處理c()方法中的異常？

Answer 2

基本上沒有。 這不是處理這些情況的建議方法。

當且僅當您可以處理它們並執行適當的操作或向調用堆棧中較高的調用方提供更多信息時（通過將其封裝在更通用的異常中），您應該捕獲異常。 如果你不能這樣做，你應該讓異常在調用堆棧中冒泡，直到有人能夠正確處理它。

Answer 3

異常的巨大優勢在於，您可以處理可以對其進行操作的問題，而不是直接在檢測到丟失文件的函數中，或者在函數的調用者或其調用者中進行處理。

但是，也必須在鏈的某處處理異常。 這些點出現的位置取決於您使用的框架，以及它的異常管理所包含的內容。 關鍵問題是：如果允許異常逃脫未被捕獲會產生不良影響，您的入境點是什么？ 典型的例子包括

1. 交互式UI應用程序中的事件處理代碼（至少在WinForms和ASP.NET中可以通過提供異常事件處理程序來集中捕獲）。
2. 集成點，您可以在其中響應外部消息（例如，從隊列中獲取消息，處理文件，偵聽命名管道，實現WCF服務）。
3. 您進行后台處理的計時器事件。
4. 線程啟動方法。

有時，您還希望捕獲低級別的常規技術錯誤，並將其重新拋出為更特定於域的異常。 這通常在設計良好的庫中完成，以保護用戶免受其內部實現細節的影響。 在企業應用程序中，您可能希望捕獲某些SqlExceptions並將它們重新拋出為特定於應用程序的異常（例如YourApp.UnknownCustomer），以便在更高級別的邏輯上處理它們。

我的建議是：盡可能處理最高級別的問題，但要確保異常捕獲有合理的例外情況可以使用。 順便說一句，除非你討厭你的用戶，否則不要向他們顯示異常及其堆棧跟蹤！ ;-)

Answer 4

我會說，這取決於你想對這些信息做些什么。

我總是試圖盡可能地接近源代碼來解決問題 - 為什么要一直運行問題，而不是試圖在它發生的地方處理它？ 為了便於閱讀和理解代碼，我也相信try / catch盡可能接近問題的根源。

如果您正在為自己編寫程序，而沒有其他任何人可以觸摸它，那么請為您和代碼做最好的事情。