樂(lè)在其中

　　客戶(hù)端可以很容易的處理好這兩種異常。如果對(duì)支票的兌付被停止了，客戶(hù)端把該支票交付特別處理。如果是因?yàn)橘Y金不足，用戶(hù)端可以從用戶(hù)的儲(chǔ)蓄帳戶(hù)里轉(zhuǎn)移一些資金到支票帳戶(hù)里，然后再試一次。

　　在使用CheckingAccount的API時(shí)，這些應(yīng)變都是可以預(yù)計(jì)的和自然的結(jié)果。他們并不是意味著軟件或運(yùn)行環(huán)境的失敗。這些異常和由于CheckingAccount類(lèi)中一些內(nèi)部實(shí)施細(xì)則引起的真正失敗是不同的。

　　設(shè)想CheckingAccount對(duì)象在數(shù)據(jù)庫(kù)里保持著一個(gè)恒定的狀態(tài)，并使用JDBC API來(lái)對(duì)之訪(fǎng)問(wèn)。在那個(gè)API里，幾乎所有的數(shù)據(jù)庫(kù)訪(fǎng)問(wèn)方法都有可能因?yàn)楹虲heckingAccount實(shí)施無(wú)關(guān)的原因而失敗。比如，有人可能忘了把數(shù)據(jù)庫(kù)服務(wù)器運(yùn)行起來(lái)，一個(gè)未有連上的網(wǎng)絡(luò)數(shù)據(jù)線(xiàn)，訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)的密碼改變了，等等。

　　JDBC依靠一種“檢查的異常”，SQLException，來(lái)匯報(bào)任何可能的錯(cuò)誤。可能出錯(cuò)的絕大多數(shù)原由都是數(shù)據(jù)庫(kù)的配置，連接，或其所在的硬件設(shè)施。對(duì)processCheck方法而言，它對(duì)上述錯(cuò)誤是無(wú)計(jì)可施的。這不應(yīng)該，因?yàn)閜rocessCheck至少了解它自己的實(shí)施細(xì)則。在調(diào)用棧里上游的方法能處理這些問(wèn)題的可能就更小。

　　CheckingAccount這個(gè)例子說(shuō)明了一個(gè)方法不能成功返回它想要的結(jié)果的兩個(gè)基本原因。這里是兩個(gè)描述性的術(shù)語(yǔ)：

應(yīng)變
    與實(shí)際預(yù)料相符，一個(gè)方法給出另外一種回應(yīng)，而這種回應(yīng)可以表達(dá)成該方法所要達(dá)到的目的之一。這個(gè)方法的調(diào)用者預(yù)料到這個(gè)情況的出現(xiàn)，并有相對(duì)的應(yīng)付之道。

故障
    在未經(jīng)計(jì)劃的情況下，一個(gè)方法不能達(dá)到它的初衷，這是一個(gè)不訴諸該方法的實(shí)施細(xì)則就很難搞清的情況。
    應(yīng)用這些術(shù)語(yǔ)，對(duì)processCheck方法而言，一個(gè)止付的命令和一個(gè)超額的提取是兩種可能的應(yīng)變。而SQLException反映了可能的故障。processCheck方法的調(diào)用者應(yīng)該能夠提供應(yīng)變，但卻不一定能有效的處理好可能發(fā)生的故障。

Java異常的匹配
    在建立應(yīng)用架構(gòu)中Java異常的規(guī)則時(shí)，以應(yīng)變和故障的方式仔細(xì)考慮好“什么可能會(huì)出錯(cuò)”是有長(zhǎng)遠(yuǎn)意義的。

　　應(yīng)變情況恰如其分地匹配給了Java檢查的異常。因?yàn)樗鼈兪欠椒ǖ恼Z(yǔ)義算法合同中不可缺少的一部分，在這里借助于編譯器的幫助來(lái)確保它們得到解決是很有道理的。如果你發(fā)現(xiàn)編譯器堅(jiān)持應(yīng)變的異常必須要處理或者在不方便的時(shí)候必須要聲明會(huì)給你帶來(lái)些麻煩，你在設(shè)計(jì)上幾乎肯定要做些重構(gòu)了。這其實(shí)是件好事。

　　出現(xiàn)故障的情況對(duì)開(kāi)發(fā)人員而言是蠻有意思的，但對(duì)軟件邏輯而言卻并非如此。那些軟件”消化問(wèn)題“的專(zhuān)家們需要關(guān)于故障的信息以便來(lái)解決問(wèn)題。因此，未檢查的異常是表示故障的很好方式。他們讓故障的通知原封不動(dòng)地從調(diào)用棧上所有的方法濾過(guò)，到達(dá)一個(gè)專(zhuān)門(mén)來(lái)捕獲它們的地方，并得到它們自身包含的有利于診斷的信息，對(duì)整個(gè)事件提供一個(gè)有節(jié)制的優(yōu)雅的結(jié)論。產(chǎn)生故障的方法不需要來(lái)聲明（異常），上游的調(diào)用方法不需要捕獲它們，方法的實(shí)施細(xì)則被正確的隱藏起來(lái)－ 以最低的代碼復(fù)雜度。

　　新一些的Java API，比如像Spring架構(gòu)和Java Data Ojects類(lèi)庫(kù)對(duì)檢查的異常幾乎沒(méi)有依賴(lài)。Hibernate ORM架構(gòu)在3.0版本里重新定義了一些關(guān)鍵功能來(lái)去除對(duì)檢查的異常的使用。這就意味著在這些架構(gòu)舉報(bào)的絕大部分異常都是不可恢復(fù)的，歸咎于錯(cuò)誤的方法調(diào)用代碼，或是類(lèi)似于數(shù)據(jù)庫(kù)服務(wù)器之類(lèi)的底層部件的失敗。特別的，強(qiáng)迫一個(gè)調(diào)用方來(lái)捕獲或聲明這些異常幾乎沒(méi)有任何好處。
設(shè)計(jì)里的故障處理

　　在你的計(jì)劃里，承認(rèn)你需要去做就邁好了有效處理好故障的第一步。對(duì)那些堅(jiān)信自己能寫(xiě)出無(wú)懈可擊的軟件的工程師們來(lái)說(shuō)，承認(rèn)這一點(diǎn)是不容易的。這里是一些有幫助的思考方式。首先，如果錯(cuò)誤俯拾即是，應(yīng)用的開(kāi)發(fā)時(shí)間將很長(zhǎng)，當(dāng)然前提是程序員自己的bug自己修理。第二，在Java類(lèi)庫(kù)中，過(guò)度使用檢查的異常來(lái)處理故障情形將迫使你的代碼要應(yīng)對(duì)好故障，即使你的調(diào)用次序完全正確。如果沒(méi)有一個(gè)故障處理的架構(gòu)，湊合的異常處理將導(dǎo)致應(yīng)用中的信息丟失。

一個(gè)成功的故障處理架構(gòu)一定要達(dá)到下面的目標(biāo)：
• 減少代碼的復(fù)雜性
• 捕獲和保存診斷性信息
• 對(duì)合適的人提醒注意
• 優(yōu)雅地退出行動(dòng)

　　故障是應(yīng)用的真實(shí)意圖的干擾。因此，用來(lái)處理它們的代碼應(yīng)盡量的少，理想上，把它們和應(yīng)用的語(yǔ)義算法部分隔離開(kāi)。故障的處理必須滿(mǎn)足那些負(fù)責(zé)改正它們的人的需要。開(kāi)發(fā)人員需要知道故障發(fā)生了，并得到能幫助他們搞清為何發(fā)生的信息。即使一個(gè)故障，在定義上而言，是不可補(bǔ)救的，好的故障處理會(huì)試著優(yōu)雅地結(jié)束引起故障的活動(dòng)。

對(duì)故障情況使用未檢查的異常

　　在做框架上的決定時(shí)，用未檢查的異常來(lái)代表故障情況是有很多原因的。Java的運(yùn)行環(huán)境對(duì)代碼的錯(cuò)誤會(huì)拋出“運(yùn)行時(shí)異常”的子類(lèi)，比如， ArithmeticException或ClassCastException。這為你的框架設(shè)了一個(gè)先例。未檢查的異常讓上游的調(diào)用方法不需要為和它們目的不相關(guān)的情況而添加代碼，從而減少了混亂。

　　你的故障處理策略應(yīng)該認(rèn)識(shí)到Java類(lèi)庫(kù)的方法和其他API可能會(huì)使用檢查的異常來(lái)代表對(duì)你的應(yīng)用而言只可能是故障的情況。在這種情形下，采用設(shè)計(jì)約定來(lái)捕獲API異常，將其以故障來(lái)看待，拋出一個(gè)未檢查的異常來(lái)指示故障的情況和捕獲診斷的信息。

　　在這種情況下拋出的特定異常類(lèi)型應(yīng)該由你的框架來(lái)定義。不要忘記一個(gè)故障異常的主要目的是傳遞記錄下來(lái)的診斷信息，以便讓人們來(lái)想出出錯(cuò)的原因。使用多個(gè)故障異常類(lèi)型可能有些過(guò)，因?yàn)槟愕募軜?gòu)對(duì)它們都一視同仁。多數(shù)情況下，一條好的，描述性強(qiáng)的信息將單一的故障類(lèi)型嵌入就夠用了。使用Java基本的 RuntimeException來(lái)代表故障情況是很容易的。截止到Java1.4，RuntimeException，和其他的拋出類(lèi)型一樣，都支持異常的嵌套，這樣你就可以捕獲和報(bào)出導(dǎo)向故障的檢查的異常。

　　你也許會(huì)為了故障報(bào)告的目的而定義你自己的未檢查的異常。這樣做可能是必要的，如果你使用Java1.3或更早的版本，它們都不支持異常的嵌套。實(shí)施一個(gè)類(lèi)似的嵌套功能來(lái)捕獲和轉(zhuǎn)換你應(yīng)用中構(gòu)成故障的檢查的異常是很簡(jiǎn)單的。你的應(yīng)用在報(bào)錯(cuò)時(shí)可能需要一個(gè)特殊的行為。這可能是你在架構(gòu)中創(chuàng)建 RuntimeException子類(lèi)的另一個(gè)原因。

建立一個(gè)故障的屏障

　　對(duì)你的故障處理架構(gòu)而言，決定拋出什么樣的異常，何時(shí)拋出是重要的決定。同樣重要的是，何時(shí)來(lái)捕獲一個(gè)故障異常，之后再怎么辦。這里的目的是讓你應(yīng)用中的功能性部分不需要處理故障。把問(wèn)題分開(kāi)來(lái)處理通常都是一件好事情，有一個(gè)中央故障處理機(jī)制長(zhǎng)遠(yuǎn)來(lái)看是很有裨益的。

　　在故障屏障的模式里，任何應(yīng)用組件都可以?huà)伋龉收袭惓＃侵挥凶鳛?#8220;故障屏障”的組件才捕獲異常。采用此種模式去除了大多數(shù)程序員為了在本地處理故障而插入的復(fù)雜的代碼。故障屏障邏輯上位于調(diào)用棧的上層，這樣在一個(gè)默認(rèn)的行動(dòng)被激發(fā)前，一個(gè)異常向上舉報(bào)的行為就被阻止了。根據(jù)不同的應(yīng)用類(lèi)型，默認(rèn)的行動(dòng)所指也不同。對(duì)一個(gè)獨(dú)立的Java應(yīng)用而言，這個(gè)行動(dòng)指活著的線(xiàn)程被停止。對(duì)一個(gè)位于應(yīng)用服務(wù)器上的Web應(yīng)用而言，這個(gè)行動(dòng)指應(yīng)用服務(wù)器向?yàn)g覽器送出不友好的（甚至令人尷尬的）回應(yīng)。

　　一個(gè)故障屏障組件的第一要?jiǎng)?wù)就是記錄下故障異常中包含的信息以為將來(lái)所用。到現(xiàn)在為止，一個(gè)應(yīng)用日志是做成此事的首選。異常的嵌套的信息，棧日志，等等，都是對(duì)診斷有價(jià)值的信息。傳遞故障信息最差的地方是通過(guò)用戶(hù)界面。把應(yīng)用的使用者卷進(jìn)查錯(cuò)的進(jìn)程對(duì)你，對(duì)你的用戶(hù)而言都不好。如果你真的很想把診斷信息放上用戶(hù)界面，那可能意味著你的日志策略需要改進(jìn)。

　　故障屏障的下一個(gè)要?jiǎng)?wù)是以一種可控的方式來(lái)結(jié)束操作。這具體的意義要取決于你應(yīng)用的設(shè)計(jì)，但通常包括產(chǎn)生一個(gè)可通用的回應(yīng)給可能正在等待的客戶(hù)端。如果你的應(yīng)用是一個(gè)Web service，這就意味著在回應(yīng)中用soap:Server的<faultcode>和通用的失敗信息< faultstring>來(lái)建立一個(gè)SOAP故障元素<fault>。如果你的應(yīng)用于瀏覽器交流，這個(gè)屏障就會(huì)安排好一個(gè)通用的 HTML回應(yīng)來(lái)表明需求是不能被處理的。

　　在一個(gè)Struts的應(yīng)用里，你的故障屏障會(huì)以一種全局異常處理器的形式出現(xiàn)，并被配置成處理RuntimeException的任何子類(lèi)。你的故障屏障類(lèi)將延伸org.apache.struts.action.ExceptionHandler類(lèi)，必要的話(huà)，重寫(xiě)它的方法來(lái)實(shí)施用戶(hù)自己的特別處理。這樣就會(huì)處理好不小心產(chǎn)生的故障情況和在處理一個(gè)Struts動(dòng)作時(shí)發(fā)現(xiàn)的故障。圖2顯示的就是應(yīng)變和故障異常。
 

圖2 應(yīng)變和故障異常

　　如果你使用的是Spring MVC架構(gòu)，你可以繼承SimpleMappingExceptionResolver類(lèi)，并配置成處理RuntimeException和它的子類(lèi)們，這樣很容易的就建起了故障屏障。通過(guò)重寫(xiě)resolveException的方法，你可以在使用父類(lèi)的方法來(lái)把需求導(dǎo)引到一個(gè)發(fā)出通用錯(cuò)誤提示的view 組件之前，加入你需要的用戶(hù)化的處理。

　　當(dāng)你的架構(gòu)包含了故障屏障，程序員都知曉了后，再寫(xiě)出一次性的故障異常的沖動(dòng)就會(huì)銳減。結(jié)果就是應(yīng)用中出現(xiàn)更干凈，更易于維護(hù)的代碼。

5 架構(gòu)中應(yīng)變的處理

　　將故障處理交與屏障后，主要組件間的應(yīng)變交流變得容易多了。一個(gè)應(yīng)變代表著與主要返回結(jié)果同等重要的另外一種方法結(jié)果。因此，檢查的異常類(lèi)型是一個(gè)能夠很好地傳遞應(yīng)變情況的存在并提供必要的信息來(lái)與它競(jìng)爭(zhēng)的工具。這個(gè)方式借助于Java編譯器的幫助來(lái)提醒程序員關(guān)于他們所用的API的方方面面以及提供全套的方法輸出的必要性。

　　僅僅使用方法的返回值類(lèi)型來(lái)傳遞簡(jiǎn)單的應(yīng)變是可能的。比如，返回一個(gè)空引用，而不是一個(gè)具體的對(duì)象，可以意味著對(duì)象由于一個(gè)已定義的原因不能被建立。 Java I/O的方法通常返回一個(gè)整數(shù)值－1，而不是字節(jié)的值或字節(jié)的數(shù)來(lái)表示文件的結(jié)尾。如果你的方法的語(yǔ)義簡(jiǎn)單到可以允許的地步，另一種返回值的方法是可以使用的，因?yàn)樗饤壛水惓?lái)的額外的花銷(xiāo)。不足之處是方法的調(diào)用方要檢測(cè)一下返回的值來(lái)判斷是主要結(jié)果，還是應(yīng)變結(jié)果。但是，編譯器沒(méi)有辦法來(lái)保證方法調(diào)用者會(huì)使用這個(gè)判斷。

　　如果一個(gè)方法有一個(gè)void的返回類(lèi)型，異常是唯一的方法來(lái)表示應(yīng)變發(fā)生了。如果一個(gè)方法返回的是一個(gè)對(duì)象的引用，那么返回值只可能是空或非空（null and non-null)。如果一個(gè)方法返回一個(gè)整數(shù)型，選擇與主要返回值不沖突的，可以表示多種應(yīng)變情況的數(shù)值是可能的。但是這樣的話(huà)，我們就進(jìn)入了錯(cuò)誤代碼檢查的世界，而這正式Java異常模式所著力避免的。
提供一些有用的信息

　　定義不同的故障報(bào)告的異常類(lèi)型是沒(méi)什么道理的，因?yàn)楣收掀琳蠈?duì)所有異常類(lèi)型一視同仁。應(yīng)變異常就有很大的不同，因?yàn)樗鼈兊脑馐且蚍椒ㄕ{(diào)用者傳遞各種情況。你的架構(gòu)可能會(huì)指出這些異常應(yīng)該繼承java.lang.Exception或一個(gè)指定的基類(lèi)。

　　不要忘記你的異常應(yīng)該是百分百的Java類(lèi)型，你可以用它來(lái)存放為你的特殊目的服務(wù)的特殊字段，方法，甚至是構(gòu)造器。比如，被假想的 processCheck()方法拋出的InsufficientFundsException這個(gè)異常類(lèi)型就應(yīng)該包含著一個(gè) OverdraftProtection的對(duì)象，它能夠從另外一個(gè)帳戶(hù)里把短缺的資金轉(zhuǎn)過(guò)來(lái)。

日志還是不要日志

　　記錄下故障異常是有用處的，因?yàn)槿罩镜哪康氖窃谝恍┬枰恼那闆r下，日志可以吸引人們的注意力。但對(duì)應(yīng)變異常而言卻并非如此。應(yīng)變異常可能代表的只是極少數(shù)情況，但是在你的應(yīng)用里，每一個(gè)情況還是會(huì)發(fā)生的。它們意味著你的應(yīng)用正在如最初的設(shè)計(jì)般正常工作著。經(jīng)常把日志代碼加進(jìn)應(yīng)變的捕獲塊里會(huì)使你的代碼晦澀難懂，而又沒(méi)有實(shí)際的好處。如果一個(gè)應(yīng)變代表了一重要的事件，在拋出一個(gè)異常應(yīng)變來(lái)警醒調(diào)用者之前，產(chǎn)生一筆日志，記錄下這個(gè)事件可能會(huì)讓這個(gè)方法更好些。

6 異常的各個(gè)方面

　　在Aspect Oriented Programming（AOP）的術(shù)語(yǔ)里，故障和應(yīng)變的處理是互相滲透的問(wèn)題。比如，要實(shí)施故障屏障的模式，所有參與的類(lèi)必須遵循通用規(guī)格：

• 故障屏障方法必須存活在遍歷參與類(lèi)的方法調(diào)用圖的最前端
• 參與類(lèi)必須使用未檢查的異常來(lái)表示故障情況
• 參與類(lèi)必須使用故障屏障期望得到的有針對(duì)性的未檢查的異常類(lèi)型
• 參與類(lèi)必須捕獲并從低端方法中把在執(zhí)行情境下注定的故障轉(zhuǎn)換成檢查的異常
• 參與類(lèi)不能干擾故障異常被傳遞到故障屏障的過(guò)程

　　這些問(wèn)題超越了那些本不相干的類(lèi)的邊界。結(jié)果就是少數(shù)零散的故障處理代碼，以及屏障類(lèi)和參與類(lèi)間暗含的耦合（這已經(jīng)比不使用模式進(jìn)步多了！）。AOP讓故障處理的問(wèn)題被封裝在通用的可以作用到參與類(lèi)的層面上。如AspectJ和Spring AOP這樣的Java AOP架構(gòu)認(rèn)為異常的處理是添加故障處理行為的切入點(diǎn)。這樣，把參與者綁定在故障屏障的模式可以放松些。故障的處理可以存活在一個(gè)獨(dú)立的，不相干的方面里，從而摒棄了屏障方法需要放在方法激活次序的最前頭的要求。

　　如果在你的架構(gòu)里利用了AOP，故障和應(yīng)變的處理是理想的在應(yīng)用里用到的在方面上的候選。對(duì)故障和應(yīng)變的處理在AOP架構(gòu)下的使用做一個(gè)完整的勘探將是將來(lái)論文里一個(gè)很有意思的題目。

7 結(jié)論

　　雖然Java異常模型自它出現(xiàn)以來(lái)就激發(fā)了熱烈的討論，如果使用正確的話(huà)，它的價(jià)值還是很大的。作為一個(gè)設(shè)計(jì)師，你的任務(wù)是建立好規(guī)格來(lái)最大限度地利用好這個(gè)模型。以故障和應(yīng)變的方式來(lái)考量異常可以幫助你做出正確的決定。合理使用好Java異常模型可以讓你的應(yīng)用簡(jiǎn)單，易維護(hù)，和正確。AOP技術(shù)將故障和應(yīng)變定位為相互滲透的問(wèn)題，這個(gè)方法可能會(huì)對(duì)你的架構(gòu)提供一些幫助。

8 引用

• Sun's Exception Tutorial Java異常的基本知識(shí)
• Does Java Need Checked Exception? Bruce Eckel對(duì)Java中檢查的異常的異議
• Exceptional Java  關(guān)于異常的很好的討論，有架構(gòu)式的異常規(guī)則來(lái)模仿
• The Exceptions Debate  來(lái)自于developerWorks的關(guān)于異常的來(lái)龍去脈
• The Apache Struts Web Application Framework  Struts的信息源
• The Spring Framework  Spring框架的信息源
• Wikipedia: Aspect Oriented Programming  一個(gè)很好的對(duì)AOP概念的介紹
• The AspectJ Project  AspectJ的信息源