關于異常,從我們一開始寫代碼的時候就開始伴隨著我們，只不過那時還沒入門，腦子里并沒有產生意識這就是異常。
異常：程序運行期間發生錯誤，
異常對象： 將程序發生的各種錯誤封裝成對象
曾記得第一次面試的時候，面試官問了我這樣的一個拐彎的問題“你平時是怎么解決出現的各種問題”，a:當時心中一驚，看別人的面經也提到了這個問題，沒有多想“首先自己找找看哪里出了出的錯誤，定位到出現錯誤的位置，看出現了什么異常”。q:那你說說有哪些異常，，產生異常的原因，如何處理的。a:空指針，超出索引異常，en en………當時挺尷尬，問到了異常我卻回答這么簡單，缺乏思考。
在實際的工作中，捕獲異常，收集分析異常對于解決問題至關重要。
Exception類分析
常見的異常類
異常捕獲
異常處理原則和建議
SystemException類繼承Exception，前者是System命名空間中所有其他異常類的基類，在捕獲異常的時候，我首先查看的就是Exception對象信息。Exception重要成員如下圖
這里寫圖片描述
1.Message屬性：產生異常原因的錯誤消息
[__DynamicallyInvokable]
public virtual string Message
{
[__DynamicallyInvokable]
get
{
if (this._message != null)
{
return this._message;
}
if (this._className == null)
{
this._className = this.GetClassName();
}
return Environment.GetRuntimeResourceString("Exception_WasThrown", new object[] { this._className });
}
}
Message屬性是只讀屬性，GetRuntimeResourceString是獲取運行時資源字符串。返回的字符串是產生異常原因的錯誤消息或者空字符串。
2.Data：的其他異常信息的鍵/值對的集合
public virtual IDictionary Data {
get {
if (_data == null)
if(IsImmutableAgileException(this)) _data = new EmptyReadOnlyDictionaryInternal();
else
_data = new ListDictionaryInternal();
return _data;
}
}
3.StackTrace：出現異常之前調用的方法名稱和簽名
public static string StackTrace
{
[SecuritySafeCritical]
get
{
new EnvironmentPermission(PermissionState.Unrestricted).Demand();
return GetStackTrace(null, true);
}
}
4.Source屬性：包含生成異常的應用程序或對象的名稱
5.TargetSite屬性：引發當前異常的方法
6.GetBaseException方法 ：返回System.Exception,它是所有異常類的“基”類。
常見的異常類
異常類型有很多，他們都是繼承自SystemException，這些異常類型大概分為以下這幾種1.與數組集合有關2.與成員訪問有關3.與參數有關4.與算術相關5.IO相關6.當然還有其他的一些異常。
1.與數組集合有關
IndexOutOfRangeException類：索引超出范圍引發的異常
ArrayTypeMismatchException類：數組集合存儲數據類型不正確引發的異常
RankException類：處理維數錯誤引發的異常
2.IO有關的異常
與IO相關的異常都繼承自IOException類，該類用于處理進行文件輸入輸出操作時所引發的異常，IOException類的5個直接派生類如下。
DirectoryNotFoundException類：沒有找到指定的目錄而引發的異常。
FileNotFoundException類：沒有找到文件而引發的異常。
EndOfStreamException類：處理已經到達流的末尾而還要繼續讀數據而引發的異常。
FileLoadException類：無法加載文件而引發的異常。
PathTooLongException類：文件名太長而引發的異常。
3.成員訪問有關的異常
與成員訪問相關的異常都繼承自MemberAccessException這個類，它繼承自SystemException。
FileAccessException：訪問字段成員失敗所引發的異常
MethodAccessException：訪問方法成員失敗引發異常
MissingMemberException：成員不存在引發的異常
4.參數相關的異常
與參數有關的異常類ArgumentException都繼承自SystemException，處理給方法成員傳遞參數時發生異常
ArgumentOutOfRangeException：當一個參數不在給定范圍內引發的異常
ArgumentNullException：參數為null（不允許null）的情況下引發的異常
5…與算術相關
ArithmeticException異常類用于處理與算術相關的異常，它的相關子類如下
DivideByZeroException：整數十進制試圖除以0引發的異常（被除數不能為0）
NotFiniteNumberException：浮點數運算中出現無窮大或非負值引發的異常
6.其他異常
NullReferenceException：當一個對象沒有實例化時并引用引發的異常
InvalidOperationException：當對方法的調用對象當前狀態無效時引發異常
InvalidCastException：處理類型轉換期間引發的異常
OutOfMemoryException：處理內存不足引發的異常
StackOverflowException：處理棧溢出引發的錯誤
異常捕獲
c#中提供try 和catch塊提供了一種結構化的異常處理方案，所有可能出現的異常都必須得到妥善的處理，try catch本身并不會影響系統的性能，在沒有發生異常的時候try catch 是不會影響系統性能的。受影響的時候是發生異常的時候。
關鍵字 try catch finally。先執行try里面的語句，如果拋出異常就會被catch捕獲。無論出不出現異常都會執行finally里面的語句。另外不常用的throw關鍵字：當問題出現時，程序拋出一個異常。
class Program
{
static void Main(string[] args)
{
DivideNumber div = new DivideNumber();
div.DivideMethod(2, 0);
Console.ReadKey();
}
}
class DivideNumber
{
int result;
public DivideNumber()
{
result = 0;
}
public void DivideMethod(int a,int b)
{
try
{
result = a / b;
}
catch (DivideByZeroException e)
{
Console.WriteLine("exception，被除數不能為0，e.message:" + e.Message);
}
finally {
Console.WriteLine($"{a}除以{b}的結果是"+result);
}
}
}
異常處理原則和建議
在實際的開發中，異常到底需要怎么寫，還是和系統的穩定性和容錯性有一定要求的。
要捕獲具體的異常
在捕獲異常的時候，我們經常習慣性寫catch(Exception ex) ,這個并非具體的異常，最好是能具體到ArgumentException、FormatException等異常類,不要拋出”new Exception()”
catch中啥也不干，異常要向頂層拋出
這種情況在自己寫demo的時候可能比較常見，在編寫catch(Exception ex)這塊代碼下啥也不干，不要這樣做。切記出現的異常要想頂層拋出
合理使用finally塊
finally關鍵字是不管拋出什么類型異常都會被執行，大多數的時候能在finally塊下執行的代碼，也能寫在catch里面。那么finally關鍵字到底在什么情況下使用比較合適呢，比如清理資源，關閉流，回復狀態等。
拋出的異常要記錄下來
當然程序中出現的異常并不是所有都要記錄下來，有些異常還是記錄下來便于分析具體的問題。一些記錄日志庫 log4net ,EIF……
不要只記錄Exception.Message的值，還需要記錄Exception.ToString()
剛剛前面的例子，我打印的e.Message ,僅僅只是輸出“嘗試除以0”，提示的錯誤信息不具體，并不推薦這樣做。Tostring方法中包含了stacktrace、內部異常信息、Message……通常這些信息比僅一個Message更重要
不要將“拋出異常”作為函數執行結果的一種
“拋出異常”應該向頂層拋出，但是不能作為方法執行結果的一種，方法的結果不能是異常類。
每個線程要包含一個try/catch塊
創建子線程去執行任務時，主線程不會知道子線程的異常情況，所以每個線程都需要一個try、catch.
來自“代碼思考者“的評論
之前在做C#項目的項目經理時，我也思考過如何有效地在項目團隊中實踐異常的處理。
首先，異常處理應該是系統設計規約的一部分出現在系統設計文檔中，而不僅僅是一種技術實現。
作為設計文檔的一部分，異常處理應該著眼于系統容錯性和穩定性（正如樓主提到的那樣）。然后在根據這個規約，再來具體討論和選擇異常處理中使用的各種技術細則。
比如，在設計服務時，必須在服務的調用接口處有異常處理，否則客戶端傳過來的任何有害數據都可能讓服務器掛掉。
比如，對異常的處理在系統的設計中，必須有明確說明，不能隨便在哪個模塊中處理異常。
