我正在繼續我的考試修訂。異常類：何時從它派生，在C＃（.Net）中？
我所遇到的基本異常類的用法，我已經看到它在試卷也。
我的問題是，當你從基本異常類派生？
如果您希望自定義類引發具有更多有意義信息的異常，那麼您可以創建一個自定義異常類，該類包含代表您的自定義類的確切數據，以及它被設計用於什麼場景？
爲什麼我的自定義異常類從「ApplicationException的」或「拋出：SecurityException」或基地「異常」類派生？
我，我應該從Exception基類派生，而不是前兩次的印象。
我的問題第二個是，你什麼時候會從其他兩個派生???是否有任何明確的 區分何時可以從這三個中的任何一個派生出來？假設沒有其他人我有我錯過了？
小幅更新：
從超越者這個問題幾乎擊中了要害。
*您應該使用哪個類來生成特定於應用程序的異常？
答：ApplicationException的類*
這是所有Design Guidelines文檔中討論。
非常有趣。從某種意義上說，我並沒有意識到ApplicationException本質上已經被宣佈爲廢棄。 – BlueMonkMN 2010-04-05 13:17:15
非常多....它說得很清楚，你不應該使用它！這對我來說是好的:) – IbrarMumtaz 2010-04-05 13:23:44
一般情況下，你想從Exception類的，最接近你想拋出異常的類型推導。如果問題在於某些參數或參數已經通過而導致問題，請使用ArgumentException。如果您需要一些定製，請從ArgumentException繼承。
根據我的經驗，使用基本Exception的唯一兩個原因是：1）當你需要一些自定義的異常，它完全不適合當前的異常模型之一或2）當一個方法理論上可以拋出一些例外情況，但你已經發現了你最有可能被拋出的那些。
通常情況下，我不從異常都繼承。只需設置Message屬性就足夠了。
感謝您的回覆。在閱讀設計指南文檔時，我會牢記這一點。 – IbrarMumtaz 2010-04-05 12:59:41
在我們最近的項目中，我們使用了一個基本的異常類。我們用它來獲得以下功能：
我們的基本異常類派生自ApplicationException。這可能是一個錯誤，有很多關於繼承深度過多的問題的討論。但是，我們對此沒有任何問題。
考試小貼士：仔細閱讀問題。祝你好運。
謝謝羅傑那！ – IbrarMumtaz 2010-04-05 13:00:28
理想情況下，異常應該按照層次結構進行分組，以便如果代碼要以同樣的方式處理多個異常，它們將全部來自公共基類。如果基礎可拋式類型是一個接口而不是一個類，那麼這樣的理想可能有點可以實現。然而，事實上，類的單繼承限制嚴重限制了層次結構的有用性。
唯一一個異常層次結構傾向於成爲一個有用的概念的時候，一個接口的實現或者一個類的新版本（被記錄爲拋出某些異常）希望允許代碼區分更多不同的條件比那些例外情況報告的要多。在這種情況下，如果有一種方法拋出的異常不是來源於已記錄的異常，那將是一個突破性的改變，因此必須拋出一個異常，該異常繼承了最好描述以前未曾預料到的狀況的記錄。這相當難看，但異常處理機制並沒有提供更好的選擇。很不幸的是，諸如IEnumerator<T>.MoveNext()之類的東西沒有被記錄爲拋出任何意味着「僅僅意味着」對不起 - 系統沒有着火或什麼的異常，而且我不知道有人改變了這個集合，但我無法推進到下一個項目，也沒有如實說出枚舉完成「，但他們沒有。
除了需要拋出與現有代碼兼容的異常情況之外，應用程序或庫使用的異常來自公共基礎可能會有幫助。它應該像YourApplicationNameException或YourLibraryNameException這樣的東西，而不是其他任何東西都可以從中衍生出來的東西。像ApplicationException之類的東西是不好的，因爲執行catch ApplicationException的代碼不僅會得到它從該類型派生的異常，還會得到任何其他庫從其派生的異常。
關於「小更新」，MSDN文檔明確指出** NOT **來自或使用[ApplicationException]（http://msdn.microsoft.com/zh-cn/library/ms229007.aspx）。 'X不要拋出或派生自ApplicationException.' – 2013-09-13 13:04:45
@Doctor Jones - 乾杯Matey，回過頭來看這個問題，我知道這句話很容易引起我的頭。 – IbrarMumtaz 2013-11-14 10:50:30