溫故而知新

子曰：“溫故而知新，可以爲師矣”。的確是這樣，對於技術知識的學習，我深有感悟。每一本書，每一個知識點，不去認真的讀上個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，下面再進行詳細的總結。

細說異常分類

上面說到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日於呼和浩特。

Java中的異常處理

溫故而知新

Java異常體系

細說異常分類

那些不好的習慣

設計一個異常處理框架

總結

druid數據源 xml配置

初窺Ansible playbook

大話Ansible Ad-Hoc命令

Ansible常用模塊基本操作

Java集合類總結

HTTP文件上傳原理

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結