最佳做法異常處理

從here發出，我不確定異常處理。 MSDN顯示了第一種方式。第二個也可以嗎？它更短，應該產生相同的輸出。最佳做法異常處理

問題：我可以使用第二種方式而沒有任何副作用嗎？

try 
{ 
    string s = null; 
    ProcessString(s); 
} 
catch (ArgumentNullException e) 
{ 
    LogError(e.Message); 
} 
catch (Exception e) 
{ 
    LogError("Error"); 
}

或

try 
{ 
    string s = null; 
    ProcessString(s); 
} 
catch (Exception e) 
{ 
    LogError((e is ArgumentNullException) ? e.Message : "Error"); 
}

來源

2017-01-30 Toshi

兩者在結果上或多或少都是相同的。但是你正在尋求最佳實踐。所以兩者都是相同的，因爲它們隱藏了表達式「Error」後面的信息。 – Ralf

如果我拋出SomeWirdException，該怎麼辦？只需在日誌中使用我的*水晶球*的記錄，以便了解哪裏出了問題...... –

@Toshi：用不同代碼實現相同的方式。 – Ralf

首先，登錄「錯誤」的字符串，當你有未知的例外是非常不好的做法。你應該記錄錯誤細節 - 消息，內部異常等。這就是爲什麼日誌記錄框架提供接受將被記錄的對象的方法。

接下來，你應該捕獲不同類型的異常，只有當你以不同的方式處理它們時。在你的情況下，有兩種情況簡單的錯誤日誌記錄，所以你不需要從其他異常區分ArgumentNullException：

try 
{ 
    ProcessString(null); 
} 
catch (Exception e) 
{ 
    LogError("Failed to process string", e); 
}

而在去年 - 不要寫你自己的日誌框架 - 看看上NLog， log4net等。

另外請注意，通常你應該只處理高級異常。例如。如果您在嘗試執行某些業務操作時有ArgumentNullException或IndexOutOfRangeException，那麼向用戶顯示這些低級別例外情況並不好。您通常將它們包裝在自定義的高級別例外中（例如DataMigrationException）並稍後處理它們

來源

2017-01-30 13:05:13

@Toshi您的行爲平等意味着什麼？ –

以相同的輸入他們產生相同的輸出 – Toshi

LogError也可以是一個顯示方法，用戶，我只想顯示'ArgumentNullException'給他 – Toshi

答案確實是「它取決於」。

這並不壞，但更具體的例外情況會更好。當你更具體時，這意味着你實際上更明確地理解你的應用程序試圖做什麼以及對它有更多的控制。你應該真正處理你期望的異常，並將其他所有事情視爲一個錯誤。

如果你特別醒目，你知道一個代碼塊或方法可以拋出異常，然後有一個更高的可能性，實際上你可以恢復，而不是僅僅記錄和最好的希望。

來源

2017-01-30 13:11:20 parameter

最佳做法異常處理

回答

相關問題