java的異常處理基礎與基本原則

今天在看hadoop原始碼時，想想自己最近在做的那個系統，發現很多異常處理的方式不對，還是按照傳統的異常處理方式（即：採用返回值來標識程序出現的異常情況）。而hadoop中很多方法的聲明是有異常拋出的，而我的系統中的許多方法的聲明都沒有拋出異常。只是判斷了異常情況，並輸出了錯誤提示，但是並沒有拋出異常。

org.apache.hadoop.hdfs.protocol套件下的Block類別的readFields()方法：

public void readFields(DataInput in) throws IOException {    this.blockId = in.readLong();    this.numBytes = in.readLong();    this.generationStamp = in.readLong();    if (numBytes < 0) {      throw new IOException("Unexpected block size: " + numBytes);//抛出异常，要是的话就不会抛出，而只是System.out.println错误提示，
    }

1.如果方法宣告名稱裡面有throws異常，那麼方法體裡面可以不拋出例外.因為可以在方法宣告中包含異常說明，但實際上卻不拋出！這樣做的好處是，要為異常先佔個位置，以後就可以拋出這種異常而不用修改修改已有的程式碼。在定義抽象基底類別和介面時這種能力很重要，這樣衍生類別或介面實作類別就能夠拋出這些預先聲明的例外。

2.為什麼有的方法宣告裡面沒有throws，但方法體裡面卻拋出了異常？從RuntimeException繼承的異常，可以在沒有異常說明throws的情況下被拋出！對於Runtime異常（也稱為非檢查的異常unchecked exception），編譯器不需要異常說明。只能在程式碼中忽略RuntimeException（及其子類別）類型的異常，其他類型的異常的處理都是由編譯器強制實施的。究其原因，RuntimeException代表的是程式錯誤。

3.執行階段例外會被Java虛擬機器自動拋出！

1. 異常處理基礎
   1.1 System.out.println是高代價的。呼叫System.out.println會降低系統吞吐量。

   1.2 在生產環境中別用例外的printStackTrace()方法。 printStackTrace預設會把呼叫的堆疊印到控制台上，在生產環境中存取控制台是不切實際的。

2. 異常處理基本原則
   2.1 如果你無法處理異常，不要捕獲該異常。

   2.2 如果要捕獲，應在離異常源近的地方捕獲它。

   2.3 不要吞沒你捕獲的異常。
   *（就是捕獲的異常，但是什麼也不做）

   2.4 除非你要重新拋出異常，否則把它log起來。

   2.5 當一個異常被重新包裝，然後重新拋出的時候，不要列印statck trace。

   2.6 用自訂的異常類，不要每次需要拋出異常的時候都拋出java.lang.Exception。方法的呼叫者可以透過throws知道有哪些異常需要處理–所以它是自我描述的。

   2.7 如果你寫業務邏輯，對於終端使用者無法修復的錯誤，系統應該拋出非檢查的異常（unchecked exception）；如果你編寫一個第三方的套件給其他的開發人員用，對於不可修復的錯誤要用需要檢查的異常（checked exception）。

   2.8 絕對不要因為寫throws語句會讓你用起來不舒服，而不宣告需要檢查的例外。

   2.9 應用程式層級的錯誤或不可修復的系統異常用非檢查的例外（unchecked exception）拋出。
   *（注意是錯誤，意味著不可修復，例如設定檔錯誤）

   2.10 根據異常的粒度組織你的方法

##相關推薦：

java異常與錯誤處理基本知識

重拾java基礎（十六）：異常總結

以上是java的異常處理基礎與基本原則的詳細內容。更多資訊請關注PHP中文網其他相關文章！