很好的異常處理

Question

在我們的應用程序中，我們使用其他團隊開發的組件。問題是我如何定義的異常處理一個很好的方式比這

try 
    { 
    someComponent.DoStuff(); 
    } 

    catch (Exception ex) 
    { 
    textLabel= ex.Message; 
    } 

部件無自定義異常類型，也許一個很好的辦法做到這一點是定義一個組件特定異常類型，並以某種方式把這個包？ 我知道這個問題是非常基本的，但我更感興趣的是讓我們說說如何做是件好事。如果調用另一個沒有自定義異常類型的組件，那麼如何以優雅的方式處理任何潛在的異常？

Answer 1

當你發現一個錯誤，你可以重新打包它，然後拋出另一個錯誤，在最基本的層面上，你可能只是增加更多的數據 - 但是，從你的建議，你也可以替換一般錯誤有一個自定義錯誤，雖然它不會克服你從組件中獲得的響應的限制，但會讓代碼進一步提升調用堆棧的機會，以更恰當地作出響應。

在短短的最基本的方式將信息添加條款

所以 - 通過拋出一個新的異常與一些額外的文本，同時仍通過原有的例外：現在

catch (Exception ex) 
{ 
    throw new Exception("This is more about where the exception occurred", ex); 
} 

，如果要定義自己的自定義組件異常您將new Exception更改爲新的ComponentSpecificException將必要的數據添加到構造函數中，但從未忘記設置內部異常。例外情況還有一個關鍵值對的數據收集，您可以在其中插入更多信息（通過創建例外，添加數據然後執行拋出）。

這些都是相當通用的 - 從那裏開始工作，在那裏你不一定能預見到你必須處理的所有異常，不要嘗試 - 設置日誌記錄，以便知道何時有一個通用異常即一個觸及最終捕獲 - 然後隨着時間的推移，在泛型之上添加異常特定的捕獲以提供更適當的響應，或者至少將錯誤打包爲較不常規的自定義異常。

不知道我是很好的解釋 - 但觀念是其難以預見每一個可能的錯誤，你想有發展以系統的方式您的應用程序，你發現新的異常的策略。

Answer 2

假設你想捕捉每種類型的異常，這個解決方案對我來說看起來很好。

Answer 3

理想情況下，您應該讓組件開發團隊爲您做這件事 - 他們希望客戶如何識別並處理組件中的錯誤？確定組件可以引發的異常是良好C＃設計的基本組成部分。

如果這不是一個選項，那麼在組件頂部實現自己的包裝以對其失敗案例進行分類是聽起來不錯的第二好事情，並且非常高貴的你進入討價還價。

Answer 4

如果第三方庫的記錄不完善（它們沒有指定每種方法可能引發的異常），則有可用的工具可以反映到代碼中並確定可能拋出的異常。這可能會讓人感到有些d（（對於任何給定的調用，可以拋出令人驚訝的數量的異常），但原則上優於捕獲一般異常類型。這裏是執行這種分析的one commercial product。

Answer 5

要麼從您使用組件的知識中，要麼使用類似Reflector的東西來分析編譯的組件，該組件可能會拋出什麼異常？爲這些提供異常處理程序是否允許您向用戶提供更好的反饋？

Answer 6

唯一合理的（更不用說「優雅」）的方式來處理異常是記錄他們，如果你不能從中恢復。

然後通知用戶出現了問題，併爲他們提供再試一次（如果它是一個互動節目）的機會。

如果您的應用程序專門用於.NET開發人員，請繼續向他們展示異常消息（儘管Exception.ToString更好，因爲它包含堆棧跟蹤）。否則，不要在用戶界面中顯示異常消息 - 這是一個安全漏洞，只會讓用戶感到困惑。