程序很難做到完美，不免有各種各樣的異常。比如程序本身有bug，比如程序打印時打印機沒有紙了，比如內存不足。為了解決這些異常，我們需要知道異常發生的原因。對于一些常見的異常，我們還可以提供一定的應對預案。C語言中的異常處理是簡單的通過函數返回值來實現的，但返回值代表的含義往往是由慣例決定的。程序員需要查詢大量的資料，才可能找到一個模糊的原因。面向對象語言，比如C++, Java, Python往往有更加復雜的異常處理機制。這里討論Java中的異常處理機制。

Java異常處理

異常處理

Java的異常處理機制很大一部分來自C++。它允許程序員跳過暫時無法處理的問題，以繼續后續的開發，或者讓程序根據異常做出更加聰明的處理。

Java使用一些特殊的對象來代表異常狀況，這樣對象稱為異常對象。當異常狀況發生時，Java會根據預先的設定，拋出(throw)代表當前狀況的對象。所謂的拋出是一種特殊的返回方式。該線程會暫停，逐層退出方法調用，直到遇到異常處理器(Exception Handler)。異常處理器可以捕捉(catch)的異常對象，并根據對象來決定下一步的行動，比如:

提醒用戶
處理異常
繼續程序
退出程序
......

異常處理器看起來如下，它由try, catch, finally以及隨后的程序塊組成。finally不是必須的。

try { ...;}catch() { ...;}catch() { ...;}finally { ...;}

這個異常處理器監視try后面的程序塊。catch的括號有一個參數，代表所要捕捉的異常的類型。catch會捕捉相應的類型及其衍生類。try后面的程序塊包含了針對該異常類型所要進行的操作。try所監視的程序塊可能拋出不止一種類型的異常，所以一個異常處理器可以有多個catch模塊。finally后面的程序塊是無論是否發生異常，都要執行的程序。

我們在try中放入可能出錯，需要監視的程序，在catch中設計應對異常的方案。

 下面是一段使用到異常處理的部分Java程序。try部分的程序是從一個文件中讀取文本行。在讀取文件的過程中，可能會有IOException發生:

BufferedReader br = new BufferedReader(new FileReader("file.txt"));try {  StringBuilder sb = new StringBuilder();  String line = br.readLine();  while (line != null) {    sb.append(line);    sb.append("/n");    line = br.readLine();  }  String everything = sb.toString();} catch(IOException e) {  e.printStackTrace();  System.out.println("IO problem");}finally {  br.close();}

如果我們捕捉到IOException類對象e的時，可以對該對象操作。比如調用對象的printStackTrace()，打印當前棧的狀況。此外，我們還向中端打印了提示"IO problem"。

無論是否有異常，程序最終會進入finally塊中。我們在finally塊中關閉文件，清空文件描述符所占據的資源。

 異常的類型

Java中的異常類都繼承自Trowable類。一個Throwable類的對象都可以拋出(throw)。

橙色: unchecked; 藍色: checked

Throwable對象可以分為兩組。一組是unchecked異常，異常處理機制往往不用于這組異常，包括:

1.Error類通常是指Java的內部錯誤以及如資源耗盡的錯誤。當Error(及其衍生類)發生時，我們不能在編程層面上解決Error，所以應該直接退出程序。

2.Exception類有特殊的一個衍生類RuntimeException。RuntimeException(及其衍生類)是Java程序自身造成的，也就是說，由于程序員在編程時犯錯。RuntimeException完全可以通過修正Java程序避免。比如將一個類型的對象轉換成沒有繼承關系的另一個類型，即ClassCastException。這類異常應該并且可以避免。

剩下的是checked異常。這些類是由編程與環境互動造成程序在運行時出錯。比如讀取文件時，由于文件本身有錯誤，發生IOException。再比如網絡服務器臨時更改URL指向，造成MalformedURLException。文件系統和網絡服務器是在Java環境之外的，并不是程序員所能控制的。如果程序員可以預期異常，可以利用異常處理機制來制定應對預案。比如文件出問題時，提醒系統管理員。再比如在網絡服務器出現問題時，提醒用戶，并等待網絡服務器恢復。異常處理機制主要是用于處理這樣的異常。

拋出異常

在上面的程序中，異常來自于我們對Java IO API的調用。我們也可以在自己的程序中拋出異常，比如下面的battery類，有充電和使用方法:

public class Test{  public static void main(String[] args)  {    Battery aBattery = new Battery();    aBattery.chargeBattery(0.5);    aBattery.useBattery(-0.5);  }}class Battery {  /**   * increase battery   */  public void chargeBattery(double p)  {    // power <= 1    if (this.power + p < 1.) {      this.power = this.power + p;    }    else {      this.power = 1.;    }  }  /**   * consume battery   */  public boolean useBattery(double p)  {    try {      test(p);    }    catch(Exception e) {      System.out.println("catch Exception");      System.out.println(e.getMessage());      p = 0.0;    }    if (this.power >= p) {      this.power = this.power - p;      return true;    }    else {      this.power = 0.0;      return false;    }  }  /**   * test usage   */  private void test(double p) throws Exception // I just throw, don't handle  {    if (p < 0) {      Exception e = new Exception("p must be positive");      throw e;    }  }  private double power = 0.0; // percentage of battery}

useBattery()表示使用電池操作。useBattery()方法中有一個參數，表示使用的電量。我們使用test()方法測試該參數。如果該參數為負數，那么我們認為有異常，并拋出。

在test中，當有異常發生時(p < 0)，我們創建一個Exception對象e，并用一個字符串作為參數。字符串中包含有異常相關的信息，該參數不是必需的。使用throw將該Exception對象拋出。

我們在useBattery()中有異常處理器。由于test()方法不直接處理它產生的異常，而是將該異常拋給上層的useBattery()，所以在test()的定義中，我們需要throws Exception來說明。

(假設異常處理器并不是位于useBattery()中，而是在更上層的main()方法中，我們也要在useBattery()的定義中增加throws Exception。)

 在catch中，我們使用getMessage()方法提取其異常中包含的信息。上述程序的運行結果如下:

catch Exceptionp must be positive

異常處理器中，我們會捕捉任意Exception類或者其衍生類異常。這往往不利于我們識別問題，特別是一段程序可能拋出多種異常時。我們可以提供一個更加具體的類來捕捉。

 自定義異常

我們可以通過繼承來創建新的異常類。在繼承時，我們往往需要重寫構造方法。異常有兩個構造方法，一個沒有參數，一個有一個String參數。比如:

class BatteryUsageException extends Exception{  public BatteryUsageException() {}  public BatteryUsageException(String msg) {    super(msg);  }}

我們可以在衍生類中提供更多異常相關的方法和信息。

 在自定義異常時，要小心選擇所繼承的基類。一個更具體的類要包含更多的異常信息，比如IOException相對于Exception。

 總結

異常處理是在解決問題，同時也是在制造問題。大型項目中，過多、過細的異常處理往往會導致程序變得一團糟。異常處理的設計并不簡單，并需要謹慎使用。