原文：
http://blog.csdn.net/pengchua/archive/2008/07/04/2610324.aspx轉載請注明該鏈接
一．異常介紹
任何的異常都是Throwable類(lèi)，并且在它之下包含兩個(gè)字類(lèi)Error / Exception，而Error僅在當在Java虛擬機中發(fā)生動(dòng)態(tài)連接失敗或其它的定位失敗的時(shí)候，Java虛擬機拋出一個(gè)Error對象。典型的簡(jiǎn)易程序不捕捉或拋出Errors對象，你可能永遠不會(huì )碰到需要實(shí)例化Error的應用，那就讓我們關(guān)心一下Exception。
Unchecked Exception.：包括 Error與RuntimeException. 這類(lèi)異常都是RuntimeException的子類(lèi)。
Checked Exception:除了Error與RuntimeException，其他剩下的異常. 這類(lèi)異常都是Exception的子類(lèi) 。在編譯時(shí)在語(yǔ)法上必須處理的異常，因此必須在語(yǔ)法上以try..catch加以處理；
二．設計異常的最佳實(shí)踐 （Best Practises for Designing the API）
1． 當要決定是采用checked exception還是Unchecked exception的時(shí)候，你要問(wèn)自己一個(gè)問(wèn)題，“如果這種異常一旦拋出，客戶(hù)端會(huì )做怎樣的補救？”
[原文：When deciding on checked exceptions vs. unchecked exceptions, ask yourself, "What action can the client code take when the exception occurs?"]
如果客戶(hù)端可以通過(guò)其他的方法恢復異常，那么這種異常就是checked exception；如果客戶(hù)端對出現的這種異常無(wú)能為力，那么這種異常就是Unchecked exception；從使用上講，當異常出現的時(shí)候要做一些試圖恢復它的動(dòng)作而不要僅僅的打印它的信息，總來(lái)的來(lái)說(shuō)，看下表：
Client's reaction when exception happens
Exception type
Client code cannot do anything
Make it an unchecked exception
Client code will take some useful recovery action based on information in exception
Make it a checked exception
此外，盡量使用unchecked exception來(lái)處理編程錯誤：因為unchecked exception不用使客戶(hù)端代碼顯示的處理它們，它們自己會(huì )在出現的地方掛起程序并打印出異常信息。Java API中提供了豐富的unchecked excetpion，譬如：NullPointerException , IllegalArgumentException 和 IllegalStateException等，因此我一般使用這些標準的異常類(lèi)而不愿親自創(chuàng )建新的異常類(lèi)，這樣使我的代碼易于理解并避免的過(guò)多的消耗內存。
2． 保護封裝性（Preserve encapsulation）
不要讓你要拋出的checked exception升級到較高的層次。例如，不要讓SQLException延伸到業(yè)務(wù)層。業(yè)務(wù)層并不需要（不關(guān)心？）SQLException。你有兩種方法來(lái)解決這種問(wèn)題：
l 轉變SQLException為另外一個(gè)checked exception，如果客戶(hù)端并不需要恢復這種異常的話(huà)；
l 轉變SQLException為一個(gè)unchecked exception，如果客戶(hù)端對這種異常無(wú)能為力的話(huà)；
多數情況下，客戶(hù)端代碼都是對SQLException無(wú)能為力的，因此你要毫不猶豫的把它轉變?yōu)橐粋€(gè)unchecked exception，看看下邊的代碼：
public void dataAccessCode(){
try{
..some code that throws SQLException
}catch(SQLException ex){
ex.printStacktrace();
}
}
上邊的catch塊緊緊打印異常信息而沒(méi)有任何的直接操作，這是情有可原的，因為對于SQLException你還奢望客戶(hù)端做些什么呢？（但是顯然這種就象什么事情都沒(méi)發(fā)生一樣的做法是不可取的）那么有沒(méi)有另外一種更加可行的方法呢？
public void dataAccessCode(){
try{
..some code that throws SQLException
}catch(SQLException ex){
throw new RuntimeException(ex);
}
}
上邊的做法是把SQLException轉換為RuntimeException，一旦SQLException被拋出，那么程序將拋出RuntimeException,此時(shí)程序被掛起并返回客戶(hù)端異常信息。
如果你有足夠的信心恢復它當SQLException被拋出的時(shí)候，那么你也可以把它轉換為一個(gè)有意義的checked exception, 但是我發(fā)現在大多時(shí)候拋出RuntimeException已經(jīng)足夠用了。
3． 不要創(chuàng )建沒(méi)有意義的異常（Try not to create new custom exceptions if they do not have useful information for client code.）
看看下面的代碼有什么問(wèn)題？
public class DuplicateUsernameException
extends Exception {}
它除了有一個(gè)“意義明確”的名字以外沒(méi)有任何有用的信息了。不要忘記Exception跟其他的Java類(lèi)一樣，客戶(hù)端可以調用其中的方法來(lái)得到更多的信息。
我們可以為其添加一些必要的方法，如下：
public class DuplicateUsernameException
extends Exception {
public DuplicateUsernameException
(String username){....}
public String requestedUsername(){...}
public String[] availableNames(){...}
}
在新的代碼中有兩個(gè)有用的方法：reqeuestedUsername(),客戶(hù)但可以通過(guò)它得到請求的名稱(chēng)；availableNames(),客戶(hù)端可以通過(guò)它得到一組有用的usernames。這樣客戶(hù)端在得到其返回的信息來(lái)明確自己的操作失敗的原因。但是如果你不想添加更多的信息，那么你可以?huà)伋鲆粋€(gè)標準的Exception:
throw new Exception("Username already taken");
更甚的情況，如果你認為客戶(hù)端并不想用過(guò)多的操作而僅僅想看到異常信息，你可以?huà)伋鲆粋€(gè)unchecked exception:
throw new RuntimeException("Username already taken");
另外，你可以提供一個(gè)方法來(lái)驗證該username是否被占用。
很有必要再重申一下，checked exception應該讓客戶(hù)端從中得到豐富的信息。要想讓你的代碼更加易讀，請傾向于用unchecked excetpion來(lái)處理程序中的錯誤（Prefer unchecked exceptions for all programmatic errors）。
4． Document exceptions.
你可以通過(guò)Javadoc’s @throws 標簽來(lái)說(shuō)明（document）你的API中要拋出checked exception或者unchecked exception。然而，我更傾向于使用來(lái)單元測試來(lái)說(shuō)明（document）異常。不管你采用哪中方式，你要讓客戶(hù)端代碼知道你的API中所要拋出的異常。這里有一個(gè)用單元測試來(lái)測試IndexOutOfBoundsException的例子：
public void testIndexOutOfBoundsException() {
ArrayList blankList = new ArrayList();
try {
blankList.get(10);
fail("Should raise an IndexOutOfBoundsException");
} catch (IndexOutOfBoundsException success) {}
}
上邊的代碼在請求blankList.get(10)的時(shí)候會(huì )拋出IndexOutOfBoundsException,如果沒(méi)有被拋出，將fail("Should raise an IndexOutOfBoundsException")顯示說(shuō)明該測試失敗。通過(guò)書(shū)寫(xiě)測試異常的單元測試，你不但可以看到異常是怎樣的工作的，而且你可以讓你的代碼變得越來(lái)越健壯。
三．使用異常的最佳實(shí)踐（Best Practices for Using Exceptions）
1． 總是要做一些清理工作（Always clean up after yourself）
如果你使用一些資源例如數據庫連接或者網(wǎng)絡(luò )連接，請記住要做一些清理工作（如關(guān)閉數據庫連接或者網(wǎng)絡(luò )連接），如果你的API拋出Unchecked exception，那么你要用try-finally來(lái)做必要的清理工作：
public void dataAccessCode(){
Connection conn = null;
try{
conn = getConnection();
..some code that throws SQLException
}catch(SQLException ex){
ex.printStacktrace();
} finally{
DBUtil.closeConnection(conn);
}
}
class DBUtil{
public static void closeConnection
(Connection conn){
try{
conn.close();
} catch(SQLException ex){
logger.error("Cannot close connection");
throw new RuntimeException(ex);
}
}
}
DBUtil是一個(gè)工具類(lèi)來(lái)關(guān)閉Connection.有必要的說(shuō)的使用的finally的重要性是不管程序是否碰到異常，它都會(huì )被執行。在上邊的例子中，finally中關(guān)閉連接，如果在關(guān)閉連接的時(shí)候出現錯誤就拋出RuntimeException.
2． 不要使用異常來(lái)控制流程（Never use exceptions for flow control）
下邊代碼中，MaximumCountReachedException被用于控制流程：
public void useExceptionsForFlowControl() {
try {
while (true) {
increaseCount();
}
} catch (MaximumCountReachedException ex) {
}
//Continue execution
}
public void increaseCount()
throws MaximumCountReachedException {
if (count >= 5000)
throw new MaximumCountReachedException();
}
上邊的useExceptionsForFlowControl()用一個(gè)無(wú)限循環(huán)來(lái)增加count直到拋出異常，這種做法并沒(méi)有說(shuō)讓代碼不易讀，但是它是程序執行效率降低。
記住，只在要會(huì )拋出異常的地方進(jìn)行異常處理。
3． 不要忽略異常
當有異常被拋出的時(shí)候，如果你不想恢復它，那么你要毫不猶豫的將其轉換為unchecked exception，而不是用一個(gè)空的catch塊或者什么也不做來(lái)忽略它，以至于從表面來(lái)看象是什么也沒(méi)有發(fā)生一樣。
4． 不要捕獲頂層的Exception
unchecked exception都是RuntimeException的子類(lèi)，RuntimeException又繼承Exception,因此，如果單純的捕獲Exception,那么你同樣也捕獲了RuntimeException,如下代碼：
try{
..
}catch(Exception ex){
}
一旦你寫(xiě)出了上邊的代碼（注意catch塊是空的），它將忽略所有的異常，包括unchecked exception.
5． Log exceptions just once
Logging the same exception stack trace more than once can confuse the programmer examining the stack trace about the original source of exception. So just log it once.
總結
這里給出了一些關(guān)于異常處理的一些最佳實(shí)踐，我并不想開(kāi)始另一輪的關(guān)于checked exception 和 unchecked exception的爭論。你可以根據自己的實(shí)際情況定制自己異常處理，我堅信我們將有更好的辦法來(lái)處理我們代碼中的異常。
