假設您有一個業務對象，其當前狀態暗示您的代碼中存在某種錯誤。或者基本上任何你使用自己的數據的情況，但它處於一個永遠不會違反一些規則的狀態。我喜歡通常檢查這些條件和假設，因爲它可以讓我在接近源頭的情況下儘早發現錯誤。但是，如果這種邏輯檢查失敗，最佳做法是什麼？如何處理代碼中無效的業務對象？
我知道Debug.Assert語句對此非常方便，但是我不是很喜歡它們，因爲它們只出現在調試模式下，而不是在測試或發佈階段，它們顯然仍然包含許多此類錯誤。我寧願被告知，這個檢查失敗了，而不是試圖調試在代碼中發生的問題。對我來說，解決方案看起來像拋出某種異常。這是一個好主意嗎？
我通常會檢查業務對象本身中的這些問題，並在忽略會導致具有無效狀態的對象時拋出異常。這樣的例外包括（但不限於）：
IllegalArgumentException對於參數在被傳遞是不能接受的，當該對象可能被驅動到一個不正確的狀態（其中不允許例如空）IllegalStateException（從場景參數無效）這樣的業務對象不同本身永遠無效。
我立即檢查這些情況。我迫切希望避免的情景是修改一個對象，使其處於無效狀態，並且稍後纔會發現（可能幾年後 - 想象一下序列化這樣的對象並從現在起將其反序列化）。這將使得發現這種問題的根源幾乎不可能。
我當然希望這些檢查發生在生產以及開發/測試階段。通常執行此類檢查的成本與正常運行所花費的時間相比可以忽略不計，特別是與您從這種情況恢復所花費的時間相比較而言。
你是絕對正確的，拋出異常。
您可以擴展Exception類並在這些情況下使用擴展版本，這將使您可以進一步處理它們，以便在需要時記錄和停止應用程序。
try
{
}
catch(MyException ex)
{
ex.LogError();
if(ex.IsCritical)
throw ex;
}
是的，這是在我看來是正確的做法。這個例外會冒出來，不會被忽視，讓你回到問題的根源。