.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，代碼如下：

var validationResult = entity.Validate()
if(!validationResult.IsValid())
{
   throw new InvalidationException(CreateMessage(validationResult));
}