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