異常爭論
異常有兩個模型：中止模型和繼續模型
中止模型認為異常不應該再回來，他做的是善后工作。而繼續模型保持異常時環境，希望再一次能運行成功。
Java采用的是前者（一般語言都是前者），而OS一般采用后者。
Java異常有三類：錯誤，運行時異常，檢查型異常。
官方的觀點是
第 39 條：最好為異常條件使用異常。也就是說，最好不為控制流使用異常。
第 40 條：為可恢復的條件使用檢查型異常，為編程錯誤使用運行時異常。
第 41 條：避免不必要的使用檢查型異常。
第 43 條：拋出與抽象相適應的異常。（使處理異常更直觀）
在異常的使用上，專家的觀點是很不一樣的
C#作者Anders根本就忽略檢查型異常。
Bruce Eckel，聲稱在使用 Java 語言多年后，他已經得出這樣的結論，認為檢查型異常是一個錯誤 —— 一個應該被聲明為失敗的試驗。
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
缺點1，代碼中包含了過多的catch，使得代碼不清晰
缺點2，有時候捕捉的異常沒有什么實際意義
缺點3，不夠清晰的錯誤指示。
缺點4，過深的異常層次。
缺點4，性能。
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Eckel 提倡將所有的異常都作為非檢查型的，并且提供將檢查型異常轉變為非檢查型異常的一個方法，同時保留當異常從棧向上擴散時捕獲特定類型的異常的能力
Rod Johnson ，他采取一個不太激進的方法。他列舉了異常的多個類別，并且為每個類別確定一個策略。一些異常本質上是次要的返回代碼（它通常指示違反業務規則），而一些異常則是“發生某種可怕錯誤”（例如數據庫連接失敗）的變種。Johnson 提倡對于第一種類別的異常（可選的返回代碼）使用檢查型異常，而對于后者使用運行時異常。在“發生某種可怕錯誤”的類別中，其動機是簡單地認識到沒有調用者能夠有效地處理該異常，因此它也可能以各種方式沿著棧向上擴散而對于中間代碼的影響保持最小（并且最小化異常淹沒的可能性）。
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
解決1：謹慎的拋出檢查型異常。或者你認為，你可以處理它。否則，包裝為運行時異常。
解決2：如果遵守1，2不是問題
解決3：異常不跨層，否則必須捕捉或者包裝。
比如持久層丟出的SalException，你或者丟棄/處理/包裝（為運行時異常），或者重新包裝為業務層異常。保持JEE層的獨立和異常的清晰性。
包裝底層異常，保持異常鏈。
解決4：如果符合1，4也不是問題。再次強調，能捕捉就捕捉。
解決5：減少異常使用，減少層次。
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
在je里面，robin認為異常是流程控制的一部分——當然，考慮到性能問題，這個流程不應該是大概率流程——也就是異常流程
例如用戶登錄
Try{
用戶登錄（用戶名，密碼）；
登錄成功；
}catch（沒有這個用戶異常 e）{
錯誤提示界面；
}
Potian則認為，沒有用戶是正常業務邏輯的一部分
If(!用戶業務層.沒有這個用戶（用戶名）)錯誤提示界面；
If(用戶業務層.檢驗密碼（用戶名，密碼）)登錄成功；
else 登錄失敗；
Potian認為不應該在一個業務中包含了過多的責任。
Ps：在servlet中，我喜歡僅僅簡單的在action中調用最好一個業務層方法就可以完成此action的任務。這意味著我的servlet非常瘦，可以比較容易的被替換。如果采用了potian的辦法，則意味著我要把業務層中的代碼前移到servlet中來，這模糊了業務層的責任。解決的辦法是回到老路子上來。
Ps：我還認為，沒有異常的業務方法表達能力太弱，異常給了他們更豐富的表達能力。這使得業務層可以更豐富的表達業務意義。避免將業務責任分散掉。
我認為在業務層中，恰恰要包含足夠的責任。不多也不要少（流程分支-2最好）。在別的層次中，要細致一點。