.NET：再論異常處理，一個真實的故事

背景

關因而使用枚舉或布爾類型來表示方法執行狀態，仍是使用異常，能夠參考這裏的文章：http://www.google.ee/search?q=site%3Awww.cnblogs.com%2Fhappyframework%2F%20%E5%BC%82%E5%B8%B8。

今天貼出一個真實的場景（一個朋友重構以前和以後的代碼）供你們參考。

一個朋友的示例

重構前

重構後

示例分析

重構前

使用枚舉或布爾類型來表示方法執行狀態，致使程序中出現了大量的if(xxx){ //異常流程處理 }，這部分代碼會充斥到全部地方，程序中包括了對異常路徑的處理，隨着調用棧的深度增長，編程更不爽，如：須要在下層的枚舉狀態之上再擴展本身的枚舉狀態。

重構後

用異常表明方法執行失敗的狀態，在邊界類（控制器）中採用AOP的方式攔截異常並自動輸出友好的Action Result給瀏覽器，程序中只有正常的代碼，看起來很是清晰。

有朋友會問：若是某些異常須要個性化處理咋辦？，答：擴展你的AOP邏輯。更簡單的作法是使用自定義異常 + catch就好了，沒有被catch的異常仍是會被攔截。

備註

關於什麼狀況使用異常？什麼狀況使用返回結果？只有一條原則：不要用異常處理正常的業務邏輯。

一個示例

你但願獲取驗證信息，而後對此作進一步的處理（包裝成UI友好的信息），這時用異常明顯不合理。而若是出現了驗證失敗，程序要當即結束，對於剛纔包裝好的驗證信息，能夠採用異常的形式返回給UI，代碼以下：

1 var validationResult = entity.Validate()
2 if(!validationResult.IsValid())
3 {
4    throw new InvalidationException(CreateMessage(validationResult));
5 }