溫故而知新 子曰：“溫故而知新，可以為師矣”。的確是這樣，對於技術知識的學習，我深有感悟。每一本書，每一個知識點，不去認真的讀上個2~3遍，根本無法理解其中的道理。藉著最近在學習SSH框架的機會，也抽時間把Java基礎知識好好再總結一遍，再系統的通過博文的形式將相關的知識樹，知識模塊總結出來。一來做 ...
溫故而知新
子曰：“溫故而知新，可以為師矣”。的確是這樣，對於技術知識的學習，我深有感悟。每一本書，每一個知識點，不去認真的讀上個2~3遍，根本無法理解其中的道理。藉著最近在學習SSH框架的機會，也抽時間把Java基礎知識好好再總結一遍，再系統的通過博文的形式將相關的知識樹，知識模塊總結出來。一來做到查缺補漏；二來從整體上再好好把握Java的基礎脈絡。
Java異常體系
寫過C/C++的程式員無不佩服Java中的異常處理，功能強大不說，而且可以做到傻瓜式入門。想想當初寫Java的時候，時不時就加上這麼一段，管它對不對，反正是好的：
try {
// 可能會發生異常的程式代碼
} catch (Exception ex) {
// 捕獲並處理try拋出的異常類型ex
} finally {
// 無論是否發生異常，都將執行的語句塊
} 就是這樣無頭無腦的用，但是這背後的東西並沒有過多的去瞭解和學習，直至有一天發現，我需要去更多的學習一下Java的異常。先從Java異常的類體系說起，如下圖所示：
上圖就是我們經常使用的一些類的繼承結構圖。這是一幅非常普通的類繼承結構圖，通過之後的學習，我們可以將上圖繼續總結，從而歸納為下麵這樣：
在Java中異常被當做對象來處理，根類是java.lang.Throwable類，所有異常類都必須直接或間接繼承自Throwable類，Throwable類分為以下兩個子類：
Error類，它是error類型異常的父類；error類型異常是程式無法處理的異常。一般發生這種異常時，JVM會選擇終止程式，因此在我們編寫程式時，並不需要關心error類異常Exception類，它是exception類型異常的父類，這類異常就是我們編碼時需要註意的異常。而對於Exception類，它又分為以下兩大類：- RuntimeException類，它是所有運行時異常的父類，典型的代表有：
NullPointerException、IndexOutOfBoundsException、IllegalArgumentException等 - 非RuntimeException類，它是所有非運行時異常的父類，典型的代表有：
IOException、SQLException等
- RuntimeException類，它是所有運行時異常的父類，典型的代表有：
關於RuntimeException和非RuntimeException，下麵再進行詳細的總結。
細說異常分類
上面說到Exception類可以分為RuntimeException類和非RuntimeException類。那麼具體來說，何為RuntimeException類異常？何又為非RuntimeException類異常呢？
RuntimeException類異常，又被稱為Unchecked Exception（非檢查異常）；Unchecked表示在編譯階段，Java編譯器不要求必須進行異常捕獲處理或者拋出聲明，而要到運行期間才能由JVM去決定是否要拋出這類異常。這些異常一般是由程式邏輯錯誤引起的，程式應該從邏輯角度儘可能避免這類異常的發生。需要註意的是，Error類錯誤也是屬於RuntimeException類異常。例如下麵這段代碼：
public class Test
{
public static void main(String[] args)
{
int[] intArray = { 1, 2, 3, 4, 5 };
System.out.println(intArray[7]); // 越界訪問數組
}
}很明顯的，我越界訪問數組了；但是在編譯的時候，這並沒有問題，直到運行時，才會拋出java.lang.ArrayIndexOutOfBoundsException異常。
非RuntimeException類異常，又被稱為Checked Exceptions（檢查異常）；這類異常表示在編譯階段，編譯器會檢查此類異常，如果代碼中有明確標明拋出此類異常的代碼，而卻沒有try...catch...這類異常處理結構，此時就會出現編譯錯誤。例如下麵這段代碼：
import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;
public class Test
{
public static void main(String[] args)
{
File file = new File("c:/city.xml");
BufferedReader reader = null;
reader = new BufferedReader(new FileReader(file));
}
}由於new FileReader(file)的聲明中明確表明瞭會拋出java.io.FileNotFoundException異常，而我在代碼中卻沒有明確的try...catch...代碼塊，導致在編譯的時候，上面這段代碼都無法通過。
這就是所謂的RuntimeException類和非RuntimeException類異常。
那些不好的習慣
在編碼的時候，必不可少的要寫各種try...catch...finally...。雖然寫的不少，基本上都是千篇一律，並沒有真正的考慮過如何把這個try...catch...finally...寫好，因此養成了以下這些毛病。
直接列印異常信息到頁面上
大家可能都見過這樣的情況，訪問某個JSP頁面出錯了以後，在頁面上顯示一堆的錯誤堆棧信息。這些信息對於開發人員來說是非常重要的，但是對於用戶來說就是“天書”。為了避免這種情況的發生，我們在編碼時就需要格外的註意，邏輯處理要正確，防止出現非檢查異常。異常耦合
我們在開發的時候，都是分模塊的，比如最流行的MVC結構，它要求各個部分應盡最大可能的解耦。但是不盡人意的是，如果處理不好異常處理代碼，則會增加模塊之間的耦合度。例如以下這段代碼：public UserInfo getUserInfoById(String id) throw SQLException { // 根據ID查詢資料庫，獲取用戶信息 }上面這段代碼咋一看沒什麼問題，但是從設計耦合角度仔細考慮一下，這裡的
SQLException污染到了上層調用代碼，調用層需要顯式的利用try...catch...捕捉，或者向更上層次進一步拋出。根據設計隔離原則，我們可以適當修改成：public UserInfo getUserInfoById(String id) { try{ // 根據ID查詢資料庫，獲取用戶信息 } catch(SQLException e){ //利用非檢測異常封裝檢測異常，降低層次耦合 throw new RuntimeException(ErrorCode, e); } finally{ //關閉連接，清理資源 } }忽略異常
我們經常寫出這樣的代碼：public UserInfo getUserInfoById(String id) { try{ // 根據ID查詢資料庫，獲取用戶信息 } catch(SQLException e){ // 列印錯誤信息 ex.printStacktrace(); } }我們捕獲了異常以後，就列印了異常堆棧信息；對於開發調試來說，還有用處，但是對於生產環境來說，我們需要將異常信息寫到日誌文件，而此處只是列印了異常，並沒有處理，接下來程式還會繼續執行，這樣就會進一步導致更嚴重的問題。所以，在代碼中這種簡單的列印錯誤，卻忽略了正確的處理異常。
利用
Exception捕捉所有潛在的異常
我們也經常寫出這樣的代碼：public UserInfo getUserInfoById(String id) { try{ // 根據ID查詢資料庫，獲取用戶信息 } catch(Exception e){ // 列印錯誤信息 throw new RuntimeException(ErrorCode, e); } }有的時候，我們會為了偷懶，就使用一個
Exception來捕獲所有的異常；但是如果這樣，如果真的出現了異常，我們就無法準確的定位具體的異常，從而為解決問題增加了難度。對此，我們就需要對拋出的異常進行細分，單獨處理每個異常。多次列印異常
有些時候，我們編寫代碼很謹慎，一旦出現了異常就趕緊捕獲異常，記錄異常堆棧，比如這樣的[代碼][3]：class A { private static Logger logger = LoggerFactory.getLogger(A.class); public void process(){ try{ //實例化 B 類，可以換成其它註入等方式 B b = new B(); b.process(); //other code might cause exception } catch(XXXException e){ //如果 B 類 process 方法拋出異常，異常會在 B 類中被列印，在這裡也會被列印，從而會列印 2 次 logger.error(e); throw new RuntimeException(/* 錯誤代碼 */ errorCode, /*異常信息*/msg, e); } } } class B{ private static Logger logger = LoggerFactory.getLogger(B.class); public void process(){ try{ //可能拋出異常的代碼 } catch(XXXException e){ logger.error(e); throw new RuntimeException(/* 錯誤代碼 */ errorCode, /*異常信息*/msg, e); } } }通過仔細的閱讀代碼，我們就會發現會多次記錄異常堆棧信息，不僅帶來效率問題，同時也會記錄了很多的冗餘信息，給問題定位帶來了麻煩；如果調用層次更多一些的話，那更不敢想象會記錄多少異常堆棧。
除了上面這些壞習慣，我們在編碼時還要註意很多，很多，這裡就不一一舉例了。
設計一個異常處理框架
說的再多，我們終究需要在我們的代碼中使用異常，那麼如何設計一個簡單、易用的異常處理框架呢？當設計一個異常處理框架時，需要基於以下幾點去考慮：
- 用戶不明白什麼是異常；出現異常時，上層一定要具有良好的用戶體驗
- 自定義一個異常，將所有其它標準異常均轉為自定義異常，實現異常的統一管理
- 下層只捕獲異常，拋出異常；異常的處理統一交給上層
- 異常信息一定要可配置化
基於上面幾點進行考慮，以後在閱讀開源代碼時，也可以基於上述幾點去分析。
總結
基礎知識的重要性不言而喻，只有明白了其中的緣由，在編碼時才能做到心中有數。希望這篇文章對大家有幫助。
2015年12月22日 於呼和浩特。
