程式總是會出錯的，因為即便開發者做得再仔細，也還是會有預料不到的情況發生，令代碼在發生例外時依然能夠保持穩定是每一位C#程式員所應掌握的關鍵技能，
.NET Framework Design Guidelines建議，如果方法不能完成呼叫者所請求的操作，那就可以考慮拋出例外，此時必須提供各種資訊，使得呼叫者能夠據此診斷問題，
此外，還必須保證如果應用程式能夠從錯誤中恢復，那么必須處在某種已知的狀態，
考慮在方法約定遭到違背時拋出例外
如果方法不能夠履行它與呼叫者所訂立的契約，那就應該讓它其拋出例外，這些無法履約的情況都應該通過例外來表示，然而要注意，由于例外并不適合當作控制程式流程的常規手段，因為拋出例外開銷很大，而且會導致代碼中很多try-catch，因此，還應該同時提供另外一套方法，使得開發者可以在執行操作之前先判斷該操作能否順利執行，以便在無法順利執行的情況下采取相應的措施，而不是等到拋出了例外之后再去處理，
用類別庫的的File.Open來舉例，它在無法完成操作時會拋出例外；但同時也提供了File.Exists來判斷檔案是否存在，所以呼叫者可以在Open前先判斷Exists，當然除了檔案不存在，檔案被占用、沒有權限等也會導致Open失敗，這是檔案操作的細節問題，但這種設計思路是可以借鑒的，
假設提供DoWork方法，按照前面的思路，可以這樣實作
public bool TryDoWork()
{
if(!TestConditions())
return false;
DoWork();
return true;
}
public void DoWork(){...}
public bool TestConditions()
{
...
}
專門針對應用程式創建例外
例外是一種用來報告錯誤的機制，有時需要創建自定義的例外，但首先要明確，并不是所有錯誤都必須表示成例外，至于哪些錯誤才需要用例外來表示，并沒有固定的規律可循，一般來說，如果某種狀況必須立刻得到處理或匯報，否則將長期影回應用程式，那么就應該拋出例外，比如資料庫發生了資料完整性問題，就需要立刻拋出例外；但如果只是無法把某個試圖的折疊、打開狀態記錄下來，因為不會造成嚴重的影響，則可以考慮只回傳錯誤碼，
然后，也不需要為所有的throw陳述句都新建一種例外類，但統統用Exception基類來拋出也不合適，
之所以要創建不同的例外類，主要原因就是為了令呼叫端能夠通過不同的catch子句去捕獲那些狀況，從而采用不同的處理方式，所以可以基于這一點來判斷要新建例外類，還是復用已有的類，
一旦決定自己來創建例外類，就必須遵循相應的原則：
- 繼承Exception基類
- 子類應該提供與Exception基類相同的建構式多載，然后把相應的作業委托基類完成
優先考慮做出強例外保證
某個操作在拋出例外的時候，要負責把自身的狀態管理好，這將直接關系到捕獲例外的人有沒有較大的余地來處理該例外，
針對例外所做的保證分成三種:
- 基本保證（basic guarantee）,確保當例外離開了產生該例外的函式后，程式中的資源不會泄漏，而且所有的物件都處在有效狀態，這相當于規定了拋出例外的那個方法在運行完其finally子句之后所必須達成的效果，
- 強保證（strong guarantee）,強保證是在基本保證的基礎上做出的，它要求整個程式的狀態不能因為某操作拋出例外而有所變化，
- no-throw保證,執行該操作的那個方法絕對不會拋出例外，
.NET CLR做出了一些基本的保證，例如會在發生例外時把記憶體管理好，除非你的資源實作了IDisposable介面，否則不太會在這種情況下出現資源泄漏問題，
no-throw保證的例子有finalizer、Dispose方法、catch的when子句，此外撰寫委托目標方法時也應對遵守no-throw保證，在這些場合，絕對不應該令任何例外脫離其范圍，
在這三種態度中，強保證是較為折中的，它既允許程式拋出例外并從中恢復，又使得開發者能夠較為簡便地處理該例外，
在強例外保證下，如果某操作拋出例外，那么應用程式的狀態必須和執行該操作之前相同，這項操作要么完全成功，要么徹底失敗，如果失敗，那么程式的狀態應與執行操作之前一模一樣，而不會出現部分成功的情形，
比如在修改集合資料時，為了實作強例外保證，可以考慮先對有待修改的資料做防御式的拷貝（defensive copy），然后在拷貝出來的資料上面執行操作，如果該操作順利執行而沒有拋出例外，那么就用這份資料把原資料替換掉，令程式的狀態得以改變；在發生例外時，原資料還是完整的，
從上面的例子也可知，要想做到強例外保證，往往會降低程式的性能，不過很多時候，從錯誤中恢復的能力，要比性能稍稍得到提升更為重要，
考慮用例外篩選器來改寫先捕獲例外再重新拋出的邏輯
在catch例外時，有時需要先判斷程式狀態、物件狀態或例外中的屬性，然后再加以處理，通常會想到在catch塊進行判斷，最后再把這個例外重新拋出，
但更推薦例外篩選器來做，因為使用例外篩選器后，編譯器所生成的代碼會先評判例外篩選器的值，然后再考慮要不要執行堆疊展開（stackunwinding），因此，發生例外的原始位置能夠保留下來，而且呼叫堆疊中的所有資訊（包括區域變數的值）也可以保持不變，
與之相對的，如果在catch塊中使用throw e重新拋出，那么系統所報告的例外發生地點就是throw陳述句所在的位置，這會導致丟失例外的堆疊資訊，直接throw雖然可以保留原始堆疊的資訊，但這種在catch塊中處理的寫法，每次都會進入catch塊、發生堆疊展開，這會產生較大的運行開銷，
合理利用例外篩選器的副作用
一般來說，例外篩選器中的條件總是應該能在某些情況下得以滿足，如果永遠都無法滿足，那么這個篩選器就失去了意義，然而有的時候，為了能監控程式中所發生的例外，還是可以考慮撰寫這種永遠回傳false的篩選器，此時呼叫堆疊還沒有真正展開，但卻可以獲取到例外的資訊，
比如可以用于例外的記錄：
public static void Filter()
{
try
{
// ...
}
catch (Exception e) when (ForWhen(e)) { }
catch (FormatException e)
{
// handle exception
}
}
public static bool ForWhen(Exception e)
{
Console.WriteLine($"captured in when, msg:{e.Message}");
return false;
}
將catch (Exception e) when (ForWhen(e)) { }放到所有的catch之前，可以將所有的例外記錄下來，但這里也需要注意：
- 這行代碼catch的應該是Exception基類，除非有特殊目的只catch某些例外
- when條件始侄訓傳false
- 執行when條件判斷的代碼應做no-throw保證
參考書籍
《Effective C#：改善C#代碼的50個有效方法（原書第3版）》 比爾·瓦格納
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/256990.html
標籤：C#
上一篇：實作復雜的自定義界面