斷言與異常(Assertion Vs Exception)
在日常編程實踐中，斷言與異常的界限不是很明顯，這也使得它們常常沒有被正確的使用。我也在不斷的與這個模糊的怪獸搏斗，僅寫此文和大家分享一下我的個人看法。我想我們還可以從很多角度來區別斷言和異常的使用場景，歡迎大家的意見和建議。
異常的使用場景：用于捕獲外部的可能錯誤
斷言的使用場景：用于捕獲內部的不可能錯誤
我們可以先仔細分析一下我們在.net中已經存在的異常。
首先，我們先不將它們看成異常，因為我們現在還沒有在異常和斷言之間劃清界限，我們先將它們看成錯誤。
當我們在編碼的第一現場考慮到可能會出現文件加載的錯誤或者服務器錯誤后，我們的第一直覺是這不是我們代碼的問題，這是我們代碼之外的問題。
例如下面這段代碼
public void WriteSnapShot(string fileName, IEnumerable<DbItem> items) { string format = "{0}/t{1}/t{2}/t{3}/t{4}/t{5}"; using (FileStream fs = new FileStream(fileName, FileMode.Create)) { using (StreamWriter sw = new StreamWriter(fs, Encoding.Unicode)) { ... foreach (var item in items) { sw.WriteLine(string.Format(format, new object[]{ item.dealMan, item.version, item.priority, item.bugStatus, item.bugNum, item.description})); } sw.Flush(); } } }上面的代碼在寫入文件，很顯然會導致IOException。稍微有經驗的程序員都會考慮到IO上可能出問題，那我們應該如何處理這個問題呢？在這個上下文中，我們別無它法，只能讓這個錯誤繼續往上拋，通知上面一層的調用者，有一個錯誤發生了，至于上一層調用者會如何處理，不是這個函數要考慮的問題。但在這個函數中，要記得一點，將當前函數中所占用的資源釋放了。因此，當我們不能控制的外部錯誤出現時，我們可以將其作為異常往上拋，這時，我們該使用異常。
現在再來看看斷言，我們還是以下面的一段代碼為例子。
public Entities.SimpleBugInfo GetSimpleBugInfo(string bugNum) { var selector = DependencyFactory.Resolve<ISelector>(); var list = selector.Return<Entities.SimpleBugInfo>( reader => new Entities.SimpleBugInfo { bugNum = reader["bugNum"].ToString(), dealMan = reader["dealMan"].ToString(), description = reader["description"].ToString(), size = Convert.ToInt32(reader["size"]), fired = Convert.ToInt32(reader["fired"]), }, "select * from bugInfo", new WhereClause(bugNum, "bugNum")); Trace.Assert(list != null); if (list.Count == 0) return null; else return list[0]; }當我貼出這段代碼時，心情有些坎坷，因為我本人在這里也糾結了很久，這也是我一直沒有將斷言和異常劃清界線的原因之一。
首先我們來回顧一下之前定義的斷言使用場景：內部不可能發生的錯誤。
selector.Return這段代碼是不是內部代碼？如果我們能夠修改Return中的代碼，說明它是內部代碼；反之，說明它是外部代碼。對于內部代碼，我們可以用斷言來保護其邏輯的不變性，當斷言被觸發時，我們就可以確信是內部代碼的錯誤，我們應該立即修復。
再糾結一下，假設Return是外部代碼，我們沒有辦法去修改它。那么上面的代碼可以有兩種寫法（如果你有更多的想法，請賜教）。
第一種，直接拋出異常。
If(list == null){ throw new NullReferenceException();}第二種，調整代碼。
if(list == null || list.Count == 0){ return null;}else{ return list[0];}當然，還有一種就是什么也不做，讓代碼執行下去直至系統為你拋出空引用錯誤。但這種做法違背了防卸性編程的原則，我們總是應行盡早或離錯誤的發生地最近的地方處理錯誤，避免錯誤數據流向系統的其它地方，產生更加嚴重的錯誤。
總結
對異?；驍嘌缘氖褂萌Q于你要防卸的是一個內部錯誤還是外部錯誤以及你認為它是一個內部錯誤或外部錯誤。如果你決定防卸一個內部錯誤，那請果斷使用斷言，反之，請使用異常。
異常處理
異常處理對于流程的控制，就像拋出與捕獲一樣分為兩個方面：
如果錯誤（或某種情況）發生，是否允許程序的控制流繼續執行下去（異常的拋出）
如果當前有異常發生，當前的代碼是否有機會讓程序的控制流進入到一個合理的狀態（異常的捕獲）
我認為可以用以上兩條，作為判斷異常處理的準繩。其實大家現在應該可以發現，這個所謂的準繩的著重點在于異常對于流程的影響，而不再是在什么情況下才使用異常。
對于流程控制，最直接的莫過于下面這段代碼
try { foreach (var lockGroup in lockGroups) { ... foreach (var newlock in lockGroup.ToArray()) { ... if (diningBlocks.Exists(n => testLockRange.IsOverlapped(n.StartTime, n.EndTime))) { status = LockStatus.InResourceBlock; throw new LockException(); } var diningAvail = availabilities.Find(n => n.Time == newlock.StartTime.TimeOfDay); if (diningAvail == null) { status = LockStatus.Failed; throw new LockException(); } ... if (newLockQuantity > diningAvail.MaxAvail && !canOverrideLock.AllowOverBook) { status = LockStatus.Override; throw new LockException(); } else if (newLockQuantity + reservedQuantity + currentLockedAvail > diningAvail.MaxAvail && !canOverrideLock.AllowOverBook) { status = LockStatus.Override; throw new LockException(); } ... } } } catch (LockException) { return new DiningLock[] { }; }在上面的代碼中，有兩層for循環，當最內層出現某種情況時，要求停止整個for循環的執行，顯然用兩個break是不行的，還得加入一個輔助變量。
但是，如果用異常，這個處理就簡單多了?？梢灾苯釉谧顑葘拥膾伋霎惓?，在最外層（或是流程控制需要的地方）捕獲異常。
在上面的代碼中，異常處理起到了流程控制的作用，而不僅僅傳遞錯誤信息，對代碼的簡化做出了貢獻。
新聞熱點
疑難解答
