.NET中從始至終要緊記異常處理的策略：拋出具體的一個異常，而不是只拋出Exception類型的異常，這樣能方便我們捕獲對應類型的異常。我們在編寫代碼時要注意考慮到應用程序最差的情況；顯示有好的信息，並提供適當的管理員聯系信息。
1、不要拋出“new Exception()”
請別這樣做。Exception是一個非常抽象的異常類，捕獲這類異常通常會產生很多負面影響。通常情況下應該定義我們自己的異常類，並且需要區分系統拋出的異常和我們自己拋出的異常。
2、不要將重要的異常信息存儲在Message屬性中
異常都封裝在類中。當你需要返回異常信息時，請將信息存儲在一些單獨的屬性中（而不要放在Message屬性中），否則人們很難從Message屬性中解析出他們需要的信息。比如當你僅僅需要糾正一下拼寫錯誤，如果你將錯誤信息和其它提示內容一起以String的形式寫在了Message屬性中，那麼別人該怎樣簡單地獲取他們要的錯誤信息呢？你很難想象到他們要做多少努力。
3、每個線程要包含一個try/catch塊
一般異常處理都放在了程序中一個比較集中的地方。每個線程都需要有一個try/catch塊，否則你會漏掉某些異常從而出現難以理解的問題。當一個程序開啟了多個線程去處理後台任務時，通常你會創建一個類型來存儲各個線程執行的結果。這時候請不要忘記了為類型增加一個字段來存儲每個線程可能發生的異常，否則的話，主線程不會知道其他線程的異常情況。在一些“即發即忘”的場合，你可能需要將主線程中的異常處理邏輯復制一份到你的子線程中去。
4、捕獲異常後要記錄下來
不管你的程序是使用何種方式記錄日志——log4net、EIF、Event Log、TraceListeners或者文本文件等，這些都不重要。重要的是：當你遇到異常後，應該在某個地方將它記錄在日志中。但是請僅僅記錄一次，否則的話，你最後會得到一個非常大的日志文件，包含了許多重復信息。
5、不要只記錄Exception.Message的值，還需要記錄Exception.ToString()
當我們談到記錄日志時，不要忘了我們應該記錄Exception.ToString()的值，而不是Exception.Message。因為Exception.ToString()包含了“堆棧跟蹤”信息，內部異常信息以及Message。通常這些信息非常重要，而如果你只記錄Exception.Message的話，你只可能看到類似“對象引用未指向堆中實例”這樣的提示。
6、要捕獲具體的異常
如果你要捕獲異常，請盡可能的捕獲具體異常（而非Exception）。好的代碼只能捕獲它知道該怎麼處理的異常
7、不要忘記使用using
僅僅調用對象的Dispose()方法是不夠的。即使異常發生時，using關鍵字也能夠防止資源洩漏
8、不要使用特殊返回值去表示方法中發生的異常
1）、直接拋出異常更快，因為使用特殊的返回值表示異常時，我們每次調用完方法時，都需要去檢查返回結果，並且這至少要多占用一個寄存器。降低代碼運行速度。
2）、特殊返回值能，並且很可能被忽略
3）、特殊返回值不能包含堆棧跟蹤信息，不能返回異常的詳細信息
4）、很多時候，不存在一個特殊值去表示方法中發生的異常，比如，除數為零的情況
9、不要將“拋出異常”作為函數執行結果的一種
這是一個非常糟糕的設計。代碼中包含太多的try/catch塊會使代碼難以理解，恰當的設計完全可以滿足一個方法返回各種不同的執行結果，如果你確實需要通過拋出異常來表示方法的執行結果，那只能說明你這個方法做了太多事情，必須進行拆分
10、可以使用“拋出異常”的方式去著重說明不能被忽略的錯誤
例如我為我的一個產品開發了一個用來登錄的API（Login），如果用戶登錄失敗，或者用戶並沒有調用Login方法，那麼他們調用其他方法時都會失敗。我在設計Login方法的時候這樣做的：如果用戶登錄失敗，它會拋出一個異常，而並不是簡單的返回false。正因為這樣，調用者（用戶）才不會忽略（他還沒登錄）這個事實。
ps: .Net異常處理的四要素
1.一個表示異常詳細信息的類。
2.一個像調用者引發異常類實例的成員。
3.調用者的一段調用異常成員的的模塊。
4.調用者的一段處理或捕獲將要發生異常的代碼塊。
