- 高效的Java異常處理
 
Java開發(fā)人員可以做出的最重要的架構(gòu)性決策之一就是如何使用Java異常模型。Java異常一直以來就是社群中許多爭(zhēng)議的靶子。有人爭(zhēng)論到，在Java語言中的異常檢查已是一場(chǎng)失敗的試驗(yàn)。本文將辨析，失敗的原因不在于Java異常模型，而在于Java類庫的設(shè)計(jì)者未能充分了解到方法失敗的兩個(gè)基本原因。

本文倡導(dǎo)一種對(duì)異常條件本質(zhì)的思考方式，并描述一些有助于設(shè)計(jì)的模式。最后，本文還將在AOP模型中，作為相互滲透的問題，來討論異常的處理。當(dāng)你能正確使用異常時(shí)，它們會(huì)有極大的好處。本文將幫助你做到這一點(diǎn)。


為何異常是如此重要

Java應(yīng)用中的異常處理在很大程度上揭示了其所基于架構(gòu)的強(qiáng)度。架構(gòu)是在應(yīng)用程序各個(gè)層次上所做出并遵循的決定。其中最重要的一個(gè)就是決定應(yīng)用程序中的類，亞系統(tǒng)，或?qū)又g溝通的方式。Java異常是Java方法將另類執(zhí)行結(jié)果交流出去的方式，所以值得在應(yīng)用架構(gòu)中給予特殊關(guān)注。

一個(gè)衡量Java設(shè)計(jì)師水平和開發(fā)團(tuán)隊(duì)紀(jì)律性的好方法就是讀讀他們應(yīng)用程序里的異常處理代碼。首先要注意的是有多少代碼用于捕獲異常，寫進(jìn)日志文件，決定發(fā)生了什么，和在不同的異常間跳轉(zhuǎn)。干凈，簡(jiǎn)捷，關(guān)聯(lián)性強(qiáng)的異常處理通常表明開發(fā)團(tuán)隊(duì)有著穩(wěn)定的使用Java異常的方式。當(dāng)異常處理代碼的數(shù)量甚至要超過其他代碼時(shí)，你可以看出團(tuán)隊(duì)之間的交流合作有很大的問題（可能在一開始就不存在），每個(gè)人都在用他們自己的方式來處理異常。

對(duì)突發(fā)異常的處理結(jié)果是可以預(yù)見的。如果你問問團(tuán)隊(duì)成員為什么異常會(huì)被拋出，捕獲，或在特定的一處代碼里忽視了異常的發(fā)生，他們的回答通常是，“我沒有別的可做”。如果你問當(dāng)他們編寫的異常真的發(fā)生了會(huì)怎么樣，他們會(huì)皺皺眉，你得到的回答類似于這樣，“我不知道。我們從沒測(cè)試過。”

你可以從客戶端的代碼判斷一個(gè)java的組件是否有效利用了java的異常。如果它們包含著大堆的邏輯去弄清楚在何時(shí)一筆操作失敗了，為何失敗，是否有彌補(bǔ)的余地，那么原因很有可能要?dú)w咎于組件的報(bào)錯(cuò)設(shè)計(jì)。錯(cuò)誤的報(bào)錯(cuò)系統(tǒng)會(huì)在客戶端產(chǎn)生大量的“記錄然后忘掉”的代碼，這些代碼鮮有用途。最差的是弄擰的邏輯，嵌套的try/catch/finally代碼塊，和一些其他的混亂而導(dǎo)致脆弱而難于管理的應(yīng)用程序。

事后再來解決Java異常的問題，或根本就不解決，是軟件項(xiàng)目產(chǎn)生混亂并導(dǎo)致滯后的主要原因。異常處理是一個(gè)在設(shè)計(jì)的各個(gè)部分都急需解決的問題。對(duì)異常處理建立一個(gè)架構(gòu)性的約定是項(xiàng)目中首要做出的決定。合理使用Java異常模型對(duì)確保你的應(yīng)用簡(jiǎn)單，易維護(hù)，和正確有著長遠(yuǎn)的影響。



解析異常

正確使用Java異常模型所包含的內(nèi)容一直以來有著很大的爭(zhēng)議。Java不是第一種支持異常算法語義的；但是，它卻是第一種通過編譯器來執(zhí)行聲明和處理某些異常的規(guī)則的語言。許多人都認(rèn)為編譯時(shí)的異常檢查對(duì)精確的軟件設(shè)計(jì)頗有幫助。圖1顯示的Java異常的等級(jí)。



圖1：Java異常的等級(jí)


通常，Java編譯器強(qiáng)迫拋出基于java.lang.Throwable的異常的方法要在它聲明中的“throws”部分加上那個(gè)異常。而且，編譯器還會(huì)證實(shí)客戶端的方法或者捕獲已聲明的異常，或者特別聲明自己也拋出同樣的異常。這些簡(jiǎn)單的規(guī)則對(duì)世界范圍的Java程序員都有深遠(yuǎn)的影響。

編譯器放松了對(duì)Throwable繼承樹中兩個(gè)分支的異常檢查。java.long.Error和java.lang.RuntimeException的子類免于編譯時(shí)的檢查。在這兩類中，軟件工程師通常對(duì)運(yùn)行中異常更感興趣。“不檢查”的異常指的是這一組，以便和所有其它“檢查”的異常區(qū)別開。

我可以想象那些接受“檢查”的異常的人，也會(huì)很看重Java的數(shù)據(jù)類型。畢竟，編譯器對(duì)數(shù)據(jù)類型施加的限制鼓勵(lì)嚴(yán)格的編碼和精確的思維。編譯時(shí)的類型檢查對(duì)減少運(yùn)行時(shí)的嚴(yán)重問題有幫助。編譯時(shí)的異常檢查也能起到類似的作用，它會(huì)提醒開發(fā)人員某個(gè)方法可能會(huì)有預(yù)想不到的結(jié)果需要處理好。

早期的建議是盡可能的使用“檢察的異常”，以此來最大限度的利用編譯器提供的幫助來寫出無錯(cuò)誤的軟件。Java類庫API的設(shè)計(jì)者們都認(rèn)同這一點(diǎn)，他們廣泛地使用“檢察的異常”來模擬類庫方法中幾乎所有的緊急應(yīng)變措施。在J2SE5.1 API規(guī)格中，“檢察的異常”類型已2比1的比率超過了“未檢查的異常”類型。

對(duì)程序員而言，看上去在Java類庫中大多數(shù)的常用方法對(duì)每一個(gè)可能的失敗都聲明了“檢察的異常”。例如，java.io包
對(duì)IOException這個(gè)“檢察的異常”就有著很大的依賴。至少有63個(gè)Java類庫包，或直接，或通過十幾個(gè)下面的子類，拋出這個(gè)異常。

I/O的失敗極其稀有，但是卻很嚴(yán)重。而且，一旦發(fā)生，從你所寫的代碼里基本上是無法補(bǔ)救的。Java程序員意識(shí)到他們不得不提供IOException或類似的不可補(bǔ)救的事件，而一個(gè)簡(jiǎn)單的Java類庫方法的調(diào)用就可能讓這些事件發(fā)生。捕獲這些異常給本來簡(jiǎn)單的代碼帶來了一定的晦澀，因?yàn)榧词乖诓东@的代碼塊里也基本上幫不上忙。但是不加以捕獲又可能更糟糕，因?yàn)榫幾g器要求你的方法必須要拋出那些異常。這樣你的實(shí)施細(xì)則就不得不暴露在外了，而通常好的面向?qū)ο蟮脑O(shè)計(jì)都是要隱藏細(xì)節(jié)的。

這樣一個(gè)不可能贏的局面導(dǎo)致了我們今天所警告的絕大多數(shù)臭名卓著的異常處理的顛覆性格局。同時(shí)也衍生了很多正確或錯(cuò)誤的補(bǔ)救之道。

一些Java界的知名人物開始質(zhì)疑Java的“檢察的異常”的模型是否是一個(gè)失敗的試驗(yàn)。有一些東西肯定是失敗的，但是這和在Java語言里加入對(duì)異常的檢查是毫無關(guān)聯(lián)的。失敗是由于在Java API的設(shè)計(jì)者們的思維里，大多數(shù)失敗的情形是雷同的，所以可以通過同一種異常傳達(dá)出去。



故障和應(yīng)變

讓我們來考慮在一個(gè)假想的銀行應(yīng)用中的CheckingAccount類。一個(gè)CheckingAcccount屬于一個(gè)用戶，記載著用戶的存款余額，也能接受存款，接受止兌的通知，和處理匯入的支票。一個(gè)CheckingAcccount對(duì)象必須協(xié)調(diào)同步線程的訪問，因?yàn)槿魏我粋€(gè)線程都可能改變它的狀態(tài)。CheckingAcccount類里processCheck的方法會(huì)接受一個(gè)Check對(duì)象為參數(shù)，通常從帳戶余額里減去支票的金額。但是一個(gè)管理支票清算的用戶端程序調(diào)用processCheck方法時(shí)，必須有兩種可能的應(yīng)變措施。一，CheckingAccount對(duì)象里可能對(duì)該支票已有一個(gè)止付的命令；二，帳戶的余額可能不足已滿足支票的金額。

所以，processCheck的方法對(duì)來自客戶端的調(diào)用可以有3種方式回應(yīng)。正常的是處理好支票，并把方法簽名里聲明的結(jié)果返回給調(diào)用方。兩種應(yīng)變的回應(yīng)則是需要與支票清算端溝通的在銀行領(lǐng)域?qū)崒?shí)在在存在的情況。processCheck方法所有3種返回結(jié)果都是按照典型的銀行支票帳戶的行為而精心設(shè)計(jì)的。

在Java里，一個(gè)自然的方法來表示上述緊急的應(yīng)變是定義兩種異常，比如StopPaymentException（止付異常）和InsufficientFundsException（余額不足異常）。一個(gè)客戶端如果忽略這些異常是不對(duì)的，因?yàn)檫@些異常在正常操作的情況下一定會(huì)被拋出。他們?nèi)缤椒ǖ暮灻粯臃从沉朔椒ǖ娜嫘袨椤?
客戶端可以很容易的處理好這兩種異常。如果對(duì)支票的兌付被停止了，客戶端把該支票交付特別處理。如果是因?yàn)橘Y金不足，用戶端可以從用戶的儲(chǔ)蓄帳戶里轉(zhuǎn)移一些資金到支票帳戶里，然后再試一次。

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

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

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

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

應(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ù)語，對(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ò)”是有長遠(yuǎn)意義的。

條件
 應(yīng)變
 故障
 
被考慮成
 設(shè)計(jì)的一部分
 一個(gè)糟糕的意外
 
預(yù)計(jì)到會(huì)發(fā)生
 經(jīng)常發(fā)生
 絕不發(fā)生 
關(guān)注方
 上游對(duì)該方法的調(diào)用者
 需要修好這個(gè)問題的人
 
舉例 另一種返回方式
 程序bug，硬件系統(tǒng)故障，配置錯(cuò)誤，丟失的文件，服務(wù)器沒有運(yùn)行 
最好的匹配
 一個(gè)檢查的異常