常見的 Exception

　　下面我們回到 Exception 的探討上來，現(xiàn)在你知道了 Exception 的父類是 Throwable，并且 Exception 有兩種異常，一種是 RuntimeException ;一種是 CheckedException，這兩種異常都應(yīng)該去捕獲。

　　下面列出了一些 Java 中常見的異常及其分類，這塊面試官也可能讓你舉出幾個(gè)常見的異常情況并將其分類

　　RuntimeException

　　UncheckedException

　　與 Exception 有關(guān)的 Java 關(guān)鍵字

　　那么 Java 中是如何處理這些異常的呢?在 Java 中有這幾個(gè)關(guān)鍵字 throws、throw、try、finally、catch 下面我們分別來探討一下

　　throws 和 throw

　　在 Java 中，異常也就是一個(gè)對象，它能夠被程序員自定義拋出或者應(yīng)用程序拋出，必須借助于 throws 和 throw 語句來定義拋出異常。

　　throws 和 throw 通常是成對出現(xiàn)的，例如

static void cacheException() throws Exception{
throw new Exception();
}

　　throw 語句用在方法體內(nèi)，表示拋出異常，由方法體內(nèi)的語句處理。

　　throws 語句用在方法聲明后面，表示再拋出異常，由該方法的調(diào)用者來處理。

　　throws 主要是聲明這個(gè)方法會拋出這種類型的異常，使它的調(diào)用者知道要捕獲這個(gè)異常。

　　throw 是具體向外拋異常的動(dòng)作，所以它是拋出一個(gè)異常實(shí)例。

　　try 、finally 、catch

　　這三個(gè)關(guān)鍵字主要有下面幾種組合方式 try...catch 、try...finally、try...catch...finally。

　　try...catch 表示對某一段代碼可能拋出異常進(jìn)行的捕獲，如下:

static void cacheException() throws Exception{
try {
System.out.println("1");
}catch (Exception e){
e.printStackTrace();
}
}
try...finally 表示對一段代碼不管執(zhí)行情況如何，都會走 finally 中的代碼
static void cacheException() throws Exception{
for (int i = 0; i < 5; i++) {
System.out.println("enter: i=" + i);
try {
System.out.println("execute: i=" + i);
continue;
} finally {
System.out.println("leave: i=" + i);
}
}
}
try...catch...finally 也是一樣的，表示對異常捕獲后，再走 finally 中的代碼邏輯。

　　JDK1.7 使用 try...with...resources 優(yōu)雅關(guān)閉資源

　　Java 類庫中有許多資源需要通過 close 方法進(jìn)行關(guān)閉。比如 InputStream、OutputStream，數(shù)據(jù)庫連接對象 Connection，MyBatis 中的 SqlSession 會話等。作為開發(fā)人員經(jīng)常會忽略掉資源的關(guān)閉方法，導(dǎo)致內(nèi)存泄漏。

　　根據(jù)經(jīng)驗(yàn)，try-finally語句是確保資源會被關(guān)閉的最佳方法，就算異常或者返回也一樣。try-catch-finally 一般是這樣來用的

static String firstLineOfFile(String path) throws IOException {
BufferedReader br = new BufferedReader(new FileReader(path));
try {
return br.readLine();
}finally {
br.close();
}
}

　　這樣看起來代碼還是比較整潔，但是當(dāng)我們添加第二個(gè)需要關(guān)閉的資源的時(shí)候，就像下面這樣:

static void copy(String src,String dst) throws Exception{
InputStream is = new FileInputStream(src);
try {

OutputStream os = new FileOutputStream(dst);
try {
byte[] buf = new byte[100];
int n;
while ((n = is.read()) >= 0){
os.write(buf,n,0);
}
}finally {
os.close();
}
}finally {
is.close();
}
}

　　這樣感覺這個(gè)方法已經(jīng)變得臃腫起來了。

　　而且這種寫法也存在諸多問題，即使 try - finally 能夠正確關(guān)閉資源，但是它不能阻止異常的拋出，因?yàn)?try 和 finally 塊中都可能有異常的發(fā)生。

　　比如說你正在讀取的時(shí)候硬盤損壞，這個(gè)時(shí)候你就無法讀取文件和關(guān)閉資源了，此時(shí)會拋出兩個(gè)異常。但是在這種情況下，第二個(gè)異常會抹掉第一個(gè)異常。在異常堆棧中也無法找到第一個(gè)異常的記錄，怎么辦，難道像這樣來捕捉異常么?

static void tryThrowException(String path) throws Exception {

BufferedReader br = new BufferedReader(new FileReader(path));
try {
String s = br.readLine();
System.out.println("s = " + s);

}catch (Exception e){
e.printStackTrace();
}finally {
try {
br.close();
}catch (Exception e){
e.printStackTrace();
}finally {
br.close();
}
}
}

　　這種寫法，雖然能解決異常拋出的問題，但是各種 try-cath-finally 的嵌套會讓代碼變得非常臃腫。

　　Java7 中引入了try-with-resources 語句時(shí)，所有這些問題都能得到解決。要使用 try-with-resources 語句，首先要實(shí)現(xiàn) AutoCloseable 接口，此接口包含了單個(gè)返回的 close 方法。Java 類庫與三方類庫中的許多類和接口，現(xiàn)在都實(shí)現(xiàn)或者擴(kuò)展了 AutoCloseable 接口。如果編寫了一個(gè)類，它代表的是必須關(guān)閉的資源，那么這個(gè)類應(yīng)該實(shí)現(xiàn) AutoCloseable 接口。

　　java 引入了 try-with-resources 聲明，將 try-catch-finally 簡化為 try-catch，這其實(shí)是一種語法糖，在編譯時(shí)會進(jìn)行轉(zhuǎn)化為 try-catch-finally 語句。

　　下面是使用 try-with-resources 的第一個(gè)范例:

/**
* 使用try-with-resources 改寫示例一
* @param path
* @return
* @throws IOException
*/static String firstLineOfFileAutoClose(String path) throws IOException {

try(BufferedReader br = new BufferedReader(new FileReader(path))){
return br.readLine();
}
}
使用 try-with-resources 改寫程序的第二個(gè)示例
static void copyAutoClose(String src,String dst) throws IOException{

try(InputStream in = new FileInputStream(src);
OutputStream os = new FileOutputStream(dst)){
byte[] buf = new byte[1000];
int n;
while ((n = in.read(buf)) >= 0){
os.write(buf,0,n);
}
}
}

　　使用 try-with-resources 不僅使代碼變得通俗易懂，也更容易診斷。以firstLineOfFileAutoClose方法為例，如果調(diào)用 readLine()和 close() 方法都拋出異常，后一個(gè)異常就會被禁止，以保留第一個(gè)異常。

　　異常處理的原則，我們在日常處理異常的代碼中，應(yīng)該遵循三個(gè)原則：

　　不要捕獲類似 Exception 之類的異常，而應(yīng)該捕獲類似特定的異常，比如 InterruptedException，方便排查問題，而且也能夠讓其他人接手你的代碼時(shí)，會減少罵你的次數(shù)。

　　不要生吞異常。這是異常處理中要特別注重的事情，因?yàn)楹芸赡軙浅ｋy以正常結(jié)束情況，如果我們不把異常拋出去，或者也沒有輸出到Logger日志中，程序可能會在后面以不可控的方式結(jié)束

　　不要在函數(shù)式編程中使用 checkedException。

　　什么是 Error?

　　Error 是程序無法處理的錯(cuò)誤，表示運(yùn)行應(yīng)用程序中較嚴(yán)重問題。大多數(shù)錯(cuò)誤與代碼編寫者執(zhí)行的操作無關(guān)，而表示代碼運(yùn)行時(shí) JVM(Java 虛擬機(jī))出現(xiàn)的問題。這些錯(cuò)誤是不可檢查的，因?yàn)樗鼈冊趹?yīng)用程序的控制和處理能力之 外，而且絕大多數(shù)是程序運(yùn)行時(shí)不允許出現(xiàn)的狀況，比如 OutOfMemoryError 和 StackOverflowError異常的出現(xiàn)會有幾種情況，這里需要先介紹一下 Java 內(nèi)存模型 JDK1.7。

　　其中包括兩部分，由所有線程共享的數(shù)據(jù)區(qū)和線程隔離的數(shù)據(jù)區(qū)組成，在上面的 Java 內(nèi)存模型中，只有程序計(jì)數(shù)器是不會發(fā)生 OutOfMemoryError 情況的區(qū)域，程序計(jì)數(shù)器控制著計(jì)算機(jī)指令的分支、循環(huán)、跳轉(zhuǎn)、異常處理和線程恢復(fù)，并且程序計(jì)數(shù)器是每個(gè)線程私有的。

　　什么是線程私有：表示的就是各條線程之間互不影響，獨(dú)立存儲的內(nèi)存區(qū)域。

　　如果應(yīng)用程序執(zhí)行的是 Java 方法，那么這個(gè)計(jì)數(shù)器記錄的就是虛擬機(jī)字節(jié)碼指令的地址;如果正在執(zhí)行的是 Native 方法，這個(gè)計(jì)數(shù)器值則為空(Undefined)。除了程序計(jì)數(shù)器外，其他區(qū)域：方法區(qū)(Method Area)、虛擬機(jī)棧(VM Stack)、本地方法棧(Native Method Stack) 和 堆(Heap) 都是可能發(fā)生 OutOfMemoryError 的區(qū)域。

　　虛擬機(jī)棧：如果線程請求的棧深度大于虛擬機(jī)棧所允許的深度，將會出現(xiàn) StackOverflowError 異常;如果虛擬機(jī)動(dòng)態(tài)擴(kuò)展無法申請到足夠的內(nèi)存，將出現(xiàn) OutOfMemoryError。本地方法棧和虛擬機(jī)棧一樣，堆：Java 堆可以處于物理上不連續(xù)，邏輯上連續(xù)，就像我們的磁盤空間一樣，如果堆中沒有內(nèi)存完成實(shí)例分配，并且堆無法擴(kuò)展時(shí)，將會拋出 OutOfMemoryError。方法區(qū)：方法區(qū)無法滿足內(nèi)存分配需求時(shí)，將拋出 OutOfMemoryError 異常。

　　一道非常經(jīng)典的面試題：NoClassDefFoundError 和 ClassNotFoundException 有什么區(qū)別?

　　在類的加載過程中， JVM 或者 ClassLoader 無法找到對應(yīng)的類時(shí)，都可能會引起這兩種異常/錯(cuò)誤，由于不同的 ClassLoader 會從不同的地方加載類，有時(shí)是錯(cuò)誤的 CLASSPATH 類路徑導(dǎo)致的這類錯(cuò)誤，有時(shí)是某個(gè)庫的 jar 包缺失引發(fā)這類錯(cuò)誤。NoClassDefFoundError 表示這個(gè)類在編譯時(shí)期存在，但是在運(yùn)行時(shí)卻找不到此類，有時(shí)靜態(tài)初始化塊也會導(dǎo)致 NoClassDefFoundError 錯(cuò)誤。

　　ClassLoader 是類路徑裝載器，在Java 中，類路徑裝載器一共有三種兩類

　　一種是虛擬機(jī)自帶的 ClassLoader，分為三種：

　　啟動(dòng)類加載器(Bootstrap) ，負(fù)責(zé)加載 $JAVAHOME/jre/lib/rt.jar

　　擴(kuò)展類加載器(Extension)，負(fù)責(zé)加載 $JAVAHOME/jre/lib/ext/*.jar

　　應(yīng)用程序類加載器(AppClassLoader)，加載當(dāng)前應(yīng)用的 classpath 的所有類

　　第二種是用戶自定義類加載器

　　Java.lang.ClassLoader 的子類，用戶可以定制類的加載方式。

　　另一方面，ClassNotFoundException 與編譯時(shí)期無關(guān)，當(dāng)你嘗試在運(yùn)行時(shí)使用反射加載類時(shí)，ClassNotFoundException 就會出現(xiàn)。

　　簡而言之，ClassNotFoundException 和 NoClassDefFoundError 都是由 CLASSPATH 中缺少類引起的，通常是由于缺少 JAR 文件而引起的，但是如果 JVM 認(rèn)為應(yīng)用運(yùn)行時(shí)找不到相應(yīng)的引用，就會拋出 NoClassDefFoundError 錯(cuò)誤;當(dāng)你在代碼中顯示的加載類比如 Class.forName() 調(diào)用時(shí)卻沒有找到相應(yīng)的類，就會拋出 java.lang.ClassNotFoundException。

　　NoClassDefFoundError 是 JVM 引起的錯(cuò)誤，是 unchecked，未經(jīng)檢查的。因此不會使用 try-catch 或者 finally 語句塊;另外，ClassNotFoundException 是受檢異常，因此需要 try-catch 語句塊或者 try-finally 語句塊包圍，否則會導(dǎo)致編譯錯(cuò)誤。

　　調(diào)用 Class.forName()、ClassLoader.findClass() 和 ClassLoader.loadClass() 等方法時(shí)可能會引起 java.lang.ClassNotFoundException

　　NoClassDefFoundError 是鏈接錯(cuò)誤，發(fā)生在鏈接階段，當(dāng)解析引用找不到對應(yīng)的類，就會觸發(fā);而 ClassNotFoundException 是發(fā)生在運(yùn)行時(shí)的異常。

　　更多關(guān)于“java培訓(xùn)”的問題，歡迎咨詢千鋒教育在線名師。千鋒教育多年辦學(xué)，課程大綱緊跟企業(yè)需求，更科學(xué)更嚴(yán)謹(jǐn)，每年培養(yǎng)泛IT人才近2萬人。不論你是零基礎(chǔ)還是想提升，都可以找到適合的班型，千鋒教育隨時(shí)歡迎你來試聽。