http://www.javaworld.com/javaworld/jw-07-1998/jw-07-exceptions.html
異常設(shè)計(jì)
譯注:異常設(shè)計(jì)一直讓我頭疼不已,《Thinking in Java》中有關(guān)于異常設(shè)計(jì)的內(nèi)容,但并不是很詳細(xì);《Effective Java》中應(yīng)該有詳細(xì)介紹吧,但一直沒有精力來啃此書。八天前在JavaWorld電子雜志上發(fā)現(xiàn)這篇八年前的文章,有一種相見恨晚的感覺,一看作者竟是 Bill Venners(前段時(shí)間拜讀他的《深入Java虛擬機(jī)》),遂惶恐譯之。
異常設(shè)計(jì)
----何使用異常的原則
摘要
本文是設(shè)計(jì)技術(shù)專欄文章,討論有關(guān)異常設(shè)計(jì)的問題。本文關(guān)注何時(shí)使用異常,并舉例演示異常的恰當(dāng)使用。此外,本文還提供一些異常設(shè)計(jì)的基本原則。
五個(gè)月前,我開始撰寫有關(guān)設(shè)計(jì)對(duì)象的文章。本文是設(shè)計(jì)文技術(shù)系列文章的延續(xù),討論了有關(guān)錯(cuò)誤報(bào)告和異常的設(shè)計(jì)原則。我假設(shè)讀者已經(jīng)知道什么是異常,以及異常是如何工作的。你若想回顧一下異常方面的知識(shí),請(qǐng)閱讀本文的姐妹篇《Java異常》。
異常的好處
異常帶來諸多好處。首先,它將錯(cuò)誤處理代碼從正常代碼(normal code)中分離出來。你可以將那些執(zhí)行概率為99.9%的代碼封裝在一個(gè)try 塊內(nèi),然后將異常處理代碼----這些代碼是不經(jīng)常執(zhí)行的----置于catch子句中。這種方式的好處是,正常代碼因此而更簡(jiǎn)潔。
如果你不知道如何處理某個(gè)方法中的一個(gè)特定錯(cuò)誤,那么你可以在方法中拋出異常,將處理權(quán)交給其他人。如果你拋出一個(gè)檢查異常(checked exception),那么Java編譯器將強(qiáng)制客戶程序員(cilent programmer)處理這個(gè)潛在異常,或者捕捉之,或者在方法的throws子句中聲明之。Java編譯器確保檢查異常被處理,這使得Java程序更為健壯。
何時(shí)拋出異常
異常應(yīng)于何時(shí)拋出?答案歸于一條原則:
如果方法遇到一個(gè)不知道如何處理的意外情況(abnormal condition),那么它應(yīng)該拋出異常。
不幸的是,雖然這條原則易于記憶和引用,但是它并不十分清晰。實(shí)際上,它引出了另一個(gè)的問題:什么是意外情況?
這是一個(gè)價(jià)值6.4萬美元的問題。是否視某特殊事件為“意外情況”是一個(gè)主觀決定。其依據(jù)通常并不明顯。正因?yàn)槿绱耍艃r(jià)值不菲。
一個(gè)更有用的經(jīng)驗(yàn)法則是:
在有充足理由將某情況視為該方法的典型功能(typical functioning )部分時(shí),避免使用異常。
因此,意外情況就是指方法的“正常功能”(normal functioning)之外的情況。請(qǐng)?jiān)试S我通過幾個(gè)例子來說明問題。
幾個(gè)例子
第一個(gè)示例使用java.io包的FileInputStream類和DataInputStream類。這是使用FileInputStream類將文件內(nèi)容發(fā)送到標(biāo)準(zhǔn)輸出(standard output)的代碼:
// In source packet in file except/ex9/Example9a.java
import java.io.*;
class Example9a {
public static void main(String[] args)
throws IOException {
if (args.length == 0) {
System.out.println("Must give filename as first arg.");
return;
}
FileInputStream in;
try {
in = new FileInputStream(args[0]);
}
catch (FileNotFoundException e) {
System.out.println("Can't find file: " + args[0]);
return;
}
int ch;
while ((ch = in.read()) != -1) {
System.out.print((char) ch);
}
System.out.println();
in.close();
}
}
在本例中,F(xiàn)ileInputStream類的read方法報(bào)告了“已到達(dá)文件末尾”的情況,但是,它并沒有采用拋出異常的方式,而是返回了一個(gè)特殊值:-1。在這個(gè)方法中,到達(dá)文件末尾被視為方法的“正常”部分,這不是意外情況。讀取字節(jié)流的通常方式是,繼續(xù)往下讀直到達(dá)字節(jié)流末尾。
與此不同的是,DataInputStream類采取了另一種方式來報(bào)告文件末尾:
// In source packet in file except/ex9b/Example9b.java
import java.io.*;
class Example9b {
public static void main(String[] args)
throws IOException {
if (args.length == 0) {
System.out.println("Must give filename as first arg.");
return;
}
FileInputStream fin;
try {
fin = new FileInputStream(args[0]);
}
catch (FileNotFoundException e) {
System.out.println("Can't find file: " + args[0]);
return;
}
DataInputStream din = new DataInputStream(fin);
try {
int i;
for (;;) {
i = din.readInt();
System.out.println(i);
}
}
catch (EOFException e) {
}
fin.close();
}
}
DataInputStream類的readInt()方法每次讀取四個(gè)字節(jié),然后將其解釋為一個(gè)int型數(shù)據(jù)。當(dāng)讀到文件末尾時(shí),readInt()方法將拋出EOFException。
這個(gè)方法拋出異常的原因有二。首先,readInt()無法返回一個(gè)特殊值來指示已經(jīng)到達(dá)文件末尾,因?yàn)樗锌赡艿姆祷刂刀际呛戏ǖ恼蛿?shù)據(jù)。(例如,它不能采用-1這個(gè)特殊值來指示文件末尾,因?yàn)?1可能就是流中的正常數(shù)據(jù)。)其次,如果readInt()在文件末尾處只讀到一個(gè)、兩個(gè)、或者三個(gè)字節(jié),那么,這就可以視為“意外情況”了。本來這個(gè)方法是要讀四個(gè)字節(jié)的,但只有一到三個(gè)字節(jié)可讀。由于該異常是使用這個(gè)類時(shí)的不可分割的部分,它被設(shè)計(jì)為檢查型異常(Exception類的子類)。客戶程序員被強(qiáng)制要求處理該異常。
指示“已到達(dá)末尾”情況的第三種方式在StringTokenizer類和Stack類中得到演示:
// In source packet in file except/ex9b/Example9c.java
// This program prints the white-space separated tokens of an
// ASCII file in reverse order of their appearance in the file.
import java.io.*;
import java.util.*;
class Example9c {
public static void main(String[] args)
throws IOException {
if (args.length == 0) {
System.out.println("Must give filename as first arg.");
return;
}
FileInputStream in = null;
try {
in = new FileInputStream(args[0]);
}
catch (FileNotFoundException e) {
System.out.println("Can't find file: " + args[0]);
return;
}
// Read file into a StringBuffer
StringBuffer buf = new StringBuffer();
try {
int ch;
while ((ch = in.read()) != -1) {
buf.append((char) ch);
}
}
finally {
in.close();
}
// Separate StringBuffer into tokens and
// push each token into a Stack
StringTokenizer tok = new StringTokenizer(buf.toString());
Stack stack = new Stack();
while (tok.hasMoreTokens()) {
stack.push(tok.nextToken());
}
// Print out tokens in reverse order.
while (!stack.empty()) {
System.out.println((String) stack.pop());
}
}
}
上面的程序逐字節(jié)讀取文件,將字節(jié)數(shù)據(jù)轉(zhuǎn)換為字符數(shù)據(jù),然后將字符數(shù)據(jù)放到StringBuffer中。它使用StringTokenizer類提取以空白字符為分隔符的token(這里是一個(gè)字符串),每次提取一個(gè)并壓入Stack中。最后,所有token都被從Stack中彈出并打印,每行打印一個(gè)。因?yàn)镾tack類實(shí)現(xiàn)的是后進(jìn)先出(LIFO)棧,所以,打印出來的數(shù)據(jù)順序和文件中的數(shù)據(jù)順序剛好相反。
StringTokenizer類和Stack類都必須能夠指示“已到達(dá)末尾”情況。StringTokenizer的構(gòu)造方法接納源字符串。每一次調(diào)用 nextToken()方法都將返回一個(gè)字符串,它是源字符串的下一個(gè)token。源字符串的所有token都必然會(huì)被消耗掉, StringTokenizer類必須通過某種方式指示已經(jīng)沒有更多的token供返回了。這種情況下,本來是可以用一個(gè)特殊的值null來指示沒有更多 token的。但是,此類的設(shè)計(jì)者采用了另一個(gè)辦法。他提供了一個(gè)額外的方法hasMoreTokens(),該方法返回一個(gè)布爾值來指示是否已到達(dá)末尾。每次調(diào)用nextToken()方法之前,你必須先調(diào)用hasMoreTokens()。
這種方法表明設(shè)計(jì)者并不認(rèn)為到達(dá)token流的末尾是意外情況。相反,它是使用這個(gè)類的常規(guī)情況。然而,如果你在調(diào)用nextToken()之前不檢查hasMoreTokens(),那么你最后會(huì)得到一個(gè)異常NoSuchElementException。雖然該異常在到達(dá)token流末尾時(shí)拋出,但它卻是一個(gè)非檢查異常(RuntimeException的子類)。該異常的拋出不是為了指示“已到達(dá)末尾”,而是指示一個(gè)軟件缺陷----你并沒有正確地使用該類。
與此類似,Stack類有一個(gè)類似的方法empty(),這個(gè)方法返回一個(gè)布爾值指示棧已經(jīng)為空。每次調(diào)用pop()之前,你都必須先調(diào)用empty ()方法。如果你忘了調(diào)用empty()方法,而直接在一個(gè)空棧上調(diào)用pop()方法,那么,你將得到一個(gè)異常EmptyStackException。雖然該異常是棧已經(jīng)為空的情況下拋出的,但它也是一個(gè)非檢查異常。它的作用不是檢測(cè)空棧,而是指示客戶代碼中的一個(gè)軟件缺陷(Stack類的不恰當(dāng)使用)。
異常表示沒有遵守契約
通過上面的例子,你應(yīng)該已經(jīng)初步了解到,何時(shí)應(yīng)拋出異常而不是使用其他方法進(jìn)行通信。若從另一個(gè)角度來看待異常,視之為“沒有遵守契約”,你可能對(duì)應(yīng)當(dāng)怎樣使用異常有更深層的理解。
面向?qū)ο蟪绦蛟O(shè)計(jì)中經(jīng)常討論的一個(gè)設(shè)計(jì)方法是契約設(shè)計(jì),它指出方法是客戶(方法的調(diào)用者)和聲明方法的類之間的契約。這個(gè)契約包括客戶必須滿足的前置條件(precondition)和方法本身必須滿足的后置條件(postcondition)。
前置條件
String類的charAt(int index)方法是一個(gè)帶有前置條件的方法。這個(gè)方法規(guī)定客戶傳入的index參數(shù)的最小取值是0,最大取值是在該String對(duì)象上調(diào)用length()方法的結(jié)果減去1。也就是說,如果字符串長(zhǎng)度為5,那么index參數(shù)的取值限于0、1、2、3、4。
后置條件
String類的charAt(int index)方法的后置條件要求返回值必須是該字符串對(duì)象在index位置上的字符數(shù)據(jù),而且該字符串對(duì)象必須保持不變。
如果客戶調(diào)用charAt()并傳入-1、和length()一樣大或者更大的值,那就認(rèn)為客戶沒有遵守契約。這種情況下,charAt()方法是不能正確執(zhí)行的,它將拋出異常StringIndexOutOfBoundsException。該異常指出客戶程序中存在某種缺陷或String類使用不當(dāng)。
如果charAt()方法接收的輸入沒有問題(客戶遵守了契約),但是由于某種原因它無法返回指定的索引上的字符數(shù)據(jù)(沒有滿足后置條件),它將拋出異常來指示這種情況。這種異常指出方法的實(shí)現(xiàn)中包含缺陷或者方法在獲得運(yùn)行時(shí)資源上存在問題。
因此,如果一個(gè)事件表示了“異常條件”或者“沒有遵守契約”,那么,Java程序所要做的就是拋出異常。
拋出什么?
一旦你決定拋出異常,你就要決定拋出什么異常。你可以拋出Throwable或其子類的對(duì)象。你可以拋出Java API中定義的、或者自定義的Throwable對(duì)象。那么,如何決定?
通常,你只需要拋出異常,而非錯(cuò)誤。Error是Throwable的子類,它用于指示災(zāi)難性的錯(cuò)誤,比如OutOfMemoryError,這個(gè)錯(cuò)誤將由JVM報(bào)告。有時(shí)一個(gè)錯(cuò)誤也可以被Java API拋出,如java.awt.AWTError。然而,在你的代碼中,你應(yīng)該嚴(yán)格限制自己只拋出異常(Exception的子類)。把錯(cuò)誤的拋出留給那些大牛人。
檢查型異常和非檢查型異常
現(xiàn)在,主要問題就是拋出檢查型異常還是非檢查型異常了。檢查型異常是Exception的子類(或者Exception類本身),但不包括RuntimeException和它的子類。非檢查型異常是RuntimeException和它的任何子類。Error類及其子類也是檢查型的,但是你應(yīng)該僅著眼于異常,你所做的應(yīng)該是決定拋出RuntimeException的子類(非檢查異常)還是Exception的子類(檢查異常)。
如果拋出了檢查型異常(而沒有捕獲它),那么你需要在方法的throws子句中聲明該異常。客戶程序員使用這個(gè)方法,他要么在其方法內(nèi)捕獲并處理這個(gè)異常,要么還在throws子句中拋出。檢查型異常強(qiáng)制客戶程序員對(duì)可能拋出的異常采取措施。
如果你拋出的是非檢查型異常,那么客戶程序員可以決定捕獲與否。然而,編譯器并不強(qiáng)制客戶程序員對(duì)非檢查型異常采取措施。事實(shí)上,他們甚至不知道可能這些異常。顯然,在非檢查型異常上客戶程序員會(huì)少費(fèi)些腦筋。
有一個(gè)簡(jiǎn)單的原則是:
如果希望客戶程序員有意識(shí)地采取措施,那么拋出檢查型異常。
一般而言,表示類的誤用的異常應(yīng)該是非檢查型異常。String類的chartAt()方法拋出的 StringIndexOutOfBoundsException就是一個(gè)非檢查型異常。String類的設(shè)計(jì)者并不打算強(qiáng)制客戶程序員每次調(diào)用 charAt(int index)時(shí)都檢查index參數(shù)的合法性。
另一方面,java.io.FileInputStream類的 read()方法拋出的是IOException,這是一個(gè)檢查異常。這個(gè)異常表明嘗試讀取文件時(shí)出錯(cuò)了。這并不意味著客戶程序員錯(cuò)誤地使用了 FileInputStream類,而是說這個(gè)方法無法履行它地職責(zé),即從文件中讀出下一個(gè)字節(jié)。FileInputStream類地設(shè)計(jì)者認(rèn)為這個(gè)意外情況很普遍,也很重要,因而強(qiáng)制客戶程序員處理之。
這就是竅門所在。如果意外情況是方法無法履行職責(zé),而你又認(rèn)為它很普遍或很重要,客戶程序員必須采取措施,那么拋出檢查型異常。否則,拋出非檢查型異常。
自定義異常類
最后,你決定實(shí)例化一個(gè)異常類,然后拋出這個(gè)異常類的實(shí)例。這里沒有具體的規(guī)則。不要拋出用一條字符串信息指出意外情況的Exception類,而是自定義一個(gè)異常類或者從已有異常類中選出一個(gè)合適的。那么,客戶程序員就可以分別為不同的異常定義相應(yīng)的catch語句,或者只捕獲一部分。
你可能希望在異常對(duì)象中嵌入一些信息,從而告訴catch子句該異常的更詳細(xì)信息。但是,你并不僅僅依賴嵌入的信息來區(qū)別不同的異常。例如,你并不希望客戶程序員查詢異常對(duì)象來決定問題發(fā)生在I/O上還是非法參數(shù)。
注意,String.charAt(int index)接收一個(gè)非法輸入時(shí),它拋出的不是RuntimeException,甚至也不是 IllegalArgumentException,而是StringIndexOutOfBoundsException。這個(gè)類型名指出問題來自字符串索引,而且這個(gè)非法索引可以通過查詢這個(gè)異常對(duì)象而找出。
結(jié)論
本文的要點(diǎn)是,異常就是意外情況,而不該用于報(bào)告那些可以作為方法的正常功能的情況。雖然使用異常可以分離常規(guī)代碼和錯(cuò)誤處理代碼,從而提高代碼的可讀性,但是,異常的不恰當(dāng)使用會(huì)降低代碼的可讀性。
以下是本文提出的異常設(shè)計(jì)原則:
- 如果方法遭遇了一個(gè)無法處理的意外情況,那么拋出一個(gè)異常。
- 避免使用異常來指出可以視為方法的常用功能的情況。
- 如果發(fā)現(xiàn)客戶違反了契約(例如,傳入非法輸入?yún)?shù)),那么拋出非檢查型異常。
- 如果方法無法履型契約,那么拋出檢查型異常,也可以拋出非檢查型異常。
- 如果你認(rèn)為客戶程序員需要有意識(shí)地采取措施,那么拋出檢查型異常。