來自微軟關于異常處理的17條軍規

1. 不要返回錯誤代碼。異常是報告框架中的錯誤的主要手段。
　　這個就不討論了,異常包含的信息量遠不是幾個錯誤代碼可以替代的.

2. 通過引發異常來報告執行故障。如果某一成員無法按預期方式成功執行，則應將這種情況視為一個執行故障并引發一個異常。
　　例如函數的參數檢測,參數不符合輸入要求,就應該引發一個異常.另外還有很多情況,只要程序無法按照預定的邏輯執行下去,就應該引發一個異常.

3.如果代碼遇到繼續執行則不安全的情況，應考慮通過調用 System.Environment.FailFast(System.String)（.NET Framework 2.0 中的一種功能）來終止進程，而不是引發異常。
　　代碼遇到異常,如果異常不是可以接受的.那么就應該立即終止.避免更嚴重的后果.“FailFast 方法使用 message 參數向 Windows Application 事件日志寫入日志項，創建應用程序的轉儲，然后終止當前進程。 如果應用程序狀態為損壞且無法修復，并且執行應用程序的 try-finally 塊和終結器將損壞程序資源，請使用 FailFast 方法而不是 Exit 方法終止應用程序。FailFast 方法終止當前進程并執行任何 CriticalFinalizerObject 對象，但不執行任何活動 try-finally 塊或終結器。 ”

4. 盡可能不對正常控制流使用異常。
　　就是不能用異常來控制業務邏輯.異常是不應該屬于正常運作范圍.你的程序Catch部分除了寫日志,釋放資源(更多時候應該放到finally塊)和拋出異常外,不應該有任何業務邏輯.

5. 考慮引發異常的性能影響.
　　異常是極其消耗資源的,當大量引發異常的時候會導致性能問題.所以,結合上一條,不要用異常控制流程.就是你的代碼正常使用下,是不需要觸發異常的.

6. 不要包含可以根據某一選項引發或不引發異常的公共成員。
　　就是不要創建類似function(bool isThrowException)這樣的函數或方法,結合第3條理解,這樣的方法已經觸犯了用異常控制流程的禁忌.觸發異常必須拋出,一直拋到你處理異常的地方.

7. 不要包含將異常作為返回值或輸出參數返回的公共成員。
　　同理,觸犯第3條軍規.

8. 考慮使用異常生成器方法。從不同的位置引發同一異常會經常發生。為了避免代碼膨脹，請使用幫助器方法創建異常并初始化其屬性。
　　使用異常幫助類. 或者這里是說自定義異常？經常發生的自定義異常可以用生成器的方法生成？或者封裝異常生成類。減少資源調用。

9. 避免從 finally 塊中顯式引發異常。可以接受因調用引發異常的方法而隱式引發的異常。
　　Finally模塊是處理異常的地方,不應該在這個地方引發異常.但是如果要調用引發異常的方法做處理而引發的異常則可以接受。

10. 考慮引發 System 命名空間中的現有異常，而不是創建自定義異常類型。如果錯誤狀態可以通過不同于現有任何其他異常的方法以編程方式進行處理，則要創建并引發自定義異常。否則，引發一個現有異常。
　　盡量引發系統異常，除非必要不必創建自定義異常類。只要日志寫得好，處理異常會很方便。

11. 引發適當的最具體（派生程度最大）的異常。
　　就是盡量讓異常靠近實際錯誤情況。而不是一律拋出SystemException了事。
 
12．不要引發 System.Exception 或 System.SystemException。
　　因為引發最普遍的異常并不能更有效的幫助人們認清楚錯誤和及時進行錯誤處理。Exception越具體，幫助越大。

13. 避免捕捉 System.Exception 或 System.SystemException，在頂級異常處理程序中除外。
　　除非在頂級最終寫Log的時候，否則不應該捕捉最普遍的異常。個人因為只應該在頂級處理捕捉異常。底層異常一律往上拋即可。

14. 對于可能在常見方案中引發異常的成員，可以考慮使用 Tester-Doer 模式來避免與異常相關的性能問題。
　　例如,對于函數的參數問題,就必須創建檢測類檢測輸入是否正確.

　　對于可能在常見方案中引發異常的成員，可以考慮使用 TryParse 模式來避免與異常相關的性能問題。
　　TryParse模式參考int.TryParse等.就是創建正常運行的條件避免拋出異常.

15. 一般不要隱藏異常轉而拋出其他異常。
　　不要將拋出的異常攔截轉而拋出自定義的異常。除非拋出的異常而包含該原始異常，否則對異常了解非常不利。

16. 定要在所有異常上都提供（至少是這樣）下列常見構造函數。確保參數的名稱和類型與在下面的代碼示例中使用的那些相同。

自定義異常MS推薦重載：

Code
public class NewException : BaseException, ISerializable
{
    public NewException()
    {
        // Add implementation.
    }
    public NewException(string message)
    {
        // Add implementation.
    }
    public NewException(string message, Exception inner)
    {
        // Add implementation.
    }

    // This constructor is needed for serialization.
   protected NewException(SerializationInfo info, StreamingContext context)
   {
        // Add implementation.
   }
}

17.在引發異常時為開發人員提供豐富且有意義的消息文本。
　　"消息應說明導致異常的原因并清楚描述避免該異常需采取的操作。消息應針對開發人員設計。確保異常消息的語法正確。頂級異常處理程序可以向應用程序終端用戶顯示異常消息。確保消息文本的每個句子都是以句號（“。”）結尾。這樣，向用戶顯示異常消息的代碼不必處理開發人員忘記最后面的句號的情況，這種處理相當麻煩而且代價很大。避免在異常消息中使用問號（“?”）和感嘆號（“!”）。不要在不要求相應權限的異常消息中透露安全敏感信息。"