拋出異常時是否真的需要包含文本描述？

Question

就像使用任何其他類或第三方庫一樣，人們也會希望將異常記錄下來，所以我總是發現有些冗餘來向它們添加文本描述。他們真的有必要嗎？

你的想法是什麼？提前致謝。

Answer 1

文字說明非常有用。有幾個原因，我認爲他們應該總是包括在內：

• 它們使您能夠清楚地瞭解異常，而無需在文檔中查找它。
• 他們讓更多的具體信息，以比一個「通用」異常的文件傳遞 - 尤其是關於異常的上下文信息可以包括
• 它們允許你進行國際化的異常消息（非常重要）
• 它們提供了一種方式（如果做得好），根據具體情況向最終用戶提供更有意義的報告。但是，這必須小心謹慎地完成（如果它是人類，您不希望只顯示最終用戶的每個例外情況）。
• 它們提供了一種簡單的方法來添加比僅僅更有意義的異常日誌記錄一類
• 他們提供標準化：異常滿足異常的用戶的期望，因爲框架是基於具有此信息

Answer 2

應該記錄一個特殊的異常，但包括文本描述允許您添加更多關於當前異常實例的上下文。

換句話說，ArgumentException不知道哪個參數有問題，參數在什麼狀態下觸發了異常。

Answer 3

是的，Message屬性和消息構造函數參數是必需的。它們不是多餘的。

這是發給另一方的信息，告訴他或她出了什麼問題。例如，拋出FileNotFoundException是不夠的 - 你應該說哪個文件。僅僅說處理Web請求時發生異常是不夠的 - 您應該說出哪個錯誤以及哪個請求。

Answer 4

當您想要向用戶顯示異常結果（儘管i18n使這有點棘手）或者當您將異常寫入日誌文件時，有一個文本描述是有用的。請記住，文本描述可以包含更多可能在運行時可用的信息，這在記錄異常時不可用。像參數名稱ArgumentNullException之類的事情馬上就要到了。

Answer 5

調試時或排除故障，我想需要做的最後一件事是不必要地閱讀文檔。我認爲有解釋性的文字配合excecptions是非常方便的。如果沒有提供，我認爲圖書館真的錯過了船。

Answer 6

異常應包括儘可能多的信息，以便完全診斷問題。這幾乎總是包含對問題的描述，因爲簡單地說，異常的類型不足以追蹤問題。

例如，考慮下列異常是否不包含消息。你仍然可以追蹤問題

• FileNotFoundException異常
• 參數*異常