前言：

Java 語言在設(shè)計之初就提供了相對完善的異常處理機制。 我們首先介紹一下 Java 中的異常。

介紹 Java 中的異常

異常是程序在運行過程中出現(xiàn)的程序異常事件，異常會中斷正在執(zhí)行的正常指令流 。 Java 中的異常分為兩大類：Exception 和 Error。

下面是 Exception 和 Error 的類定義：

public class Exception extends Throwable {}
public class Error extends Throwable {}

Exception 和 Error 都繼承了 Throwable 類，在 Java 中只有 Throwable 類型的實例才可以被拋出（throw）或者被捕獲（catch）。 Exception 和 Error 體現(xiàn)了 Java 平臺設(shè)計者對不同異常情況的分類。 下面我們逐一介紹 Error 和 Exception。

介紹 Error

Error 類對象一般是由虛擬機生成并拋出，絕大部分的 Error 都會導(dǎo)致虛擬機自身處于不可恢復(fù)的狀態(tài)，是程序無法控制和處理的。當出現(xiàn) Error 時，一般會選擇終止線程。 Error 中最常見的是虛擬機運行錯誤（VirtualMachineError 抽象類）。

虛擬機運行錯誤中最常見的有：

• 內(nèi)存溢出（OutOfMemoryError）：由于內(nèi)存不足，虛擬機沒有可分配的內(nèi)存了，垃圾回收器也不能釋放更多的內(nèi)存，那么虛擬機拋出 OutOfMemoryError
• 棧溢出（StackOverflowError）：如果一個線程已用的棧大小 超過 配置的允許最大的棧大小，那么虛擬機拋出 StackOverflowError

介紹 Exception

Exception 有兩種類型「編譯時異?！购汀高\行時異常」

• 「編譯時異?！箤?yīng) Java 的 Exception 類
• 「運行時異常」對應(yīng) Java 的 RuntimeException 類（RuntimeException 類繼承 Exception 類 ）

下面是 Exception、RuntimeException 類的定義：

public class Exception extends Throwable {}
public class RuntimeException extends Exception {}

對于「運行時異?！梗覀冊诰帉懘a的時候，可以不用主動去 try-catch 捕獲（不強制要求），編譯器在編譯代碼的時候，并不會檢查代碼是否有對運行時異常做了處理。 相反，對于「編譯時異?！?，我們在編寫代碼的時候，必須主動去 try-catch 獲取 或者 在函數(shù)定義中聲明向上拋出異常（throws），否則編譯就會報錯。

所以：

• 「運行時異?！挂步凶鞣鞘軝z異常（Unchecked Exception）
• 「編譯時異常」也叫作受檢異常（Checked Exception）

在函數(shù)拋出異常的時候，，我們該怎么處理呢？是吞掉還是向上拋出？ 如果選擇向上拋出，我們應(yīng)該選擇拋出哪種類型的異常呢？是受檢異常還是非受檢異常？ 我們下文會對此介紹。

常見的編譯時異常有：

• FileNotFoundException：當嘗試打開由指定路徑表示的文件失敗時拋出
• ClassNotFoundException：當應(yīng)用程序嘗試通過其字符串名稱加載類時拋出，以下三種方法加載
  • Class.forName(java.lang.String)
  • ClassLoader.findSystemClass(java.lang.String)
  • ClassLoader.loadClass(java.lang.String, boolean)

常見的運行時異常有：

• 非法參數(shù)異常（IllegalArgumentException）：當傳入了非法或不正確的參數(shù)時拋出
• 空指針異常（NullPointerException）：當在需要對象的情況下使用了 null 時拋出。
• 下標訪問越界異常（IndexOutOfBoundsException）：當某種索引（例如數(shù)組，字符串或向量）的索引超出范圍時拋出。
• 類型轉(zhuǎn)換異常（ClassCastException）：當嘗試將對象轉(zhuǎn)換為不是實例的子類時拋出。
• 運算異常（ArithmeticException）：運算條件出現(xiàn)異常時拋出。例如，“除以零” 的整數(shù)。

Java 異常類的結(jié)構(gòu)

如何處理函數(shù)拋出的異常

在函數(shù)拋出異常的時候，我們該怎么處理呢？是吞掉還是向上拋出？ 如果選擇向上拋出，我們應(yīng)該選擇拋出哪種類型的異常呢？是受檢異常還是非受檢異常？ 下面我們就對此介紹。

吞掉 or 拋出

在函數(shù)拋出異常的時候，我們該怎么處理？是吞掉還是向上拋出？

總結(jié)一下，在函數(shù)拋出異常的時候，感興趣的可以自己部署一套相關(guān)的環(huán)境自己嘗試練習下。

• 直接吞掉
• 原封不動地 re-throw
• 包裝成新的異常 re-throw

直接吞掉。具體的代碼示例如下所示：

public void func1() throws Exception1 {
    // ...
}

public void func2() {
    //...
    try {
        func1();
    } catch (Exception1 e) {
        //吐掉：try-catch打印日志
        log.warn("...", e);
    }
    //...
}

原封不動地 re-throw。具體的代碼示例如下所示：

public void func1() throws Exception1 {
    // ...
}

//原封不動的re-throw Exception1
public void func2() throws Exception1 {
    //...
    func1();
    //...
}

包裝成新的異常 re-throw。具體的代碼示例如下所示：

public void func1() throws Exception1 {
    // ...
}
public void func2() throws Exception2 {
    //...
    try {
        func1();
    } catch (Exception1 e) {
        // wrap成新的Exception2然后re-throw
        throw new Exception2("...", e);
    }
    //...
}

當我們面對函數(shù)拋出異常的時候，應(yīng)該選擇上面的哪種處理方式呢？我總結(jié)了下面三個參考原則：

• 如果 func1 () 拋出的異常是可以恢復(fù)，且 func2 () 的調(diào)用方并不關(guān)心此異常，我們完全可以在 func2 () 內(nèi)將 func1 () 拋出的異常吞掉；
• 如果 func1 () 拋出的異常對 func2 () 的調(diào)用方來說，也是可以理解的、關(guān)心的 ，并且在業(yè)務(wù)概念上有一定的相關(guān)性，我們可以選擇直接將 func1 拋出的異常 re-throw；
• 如果 func1 () 拋出的異常太底層，對 func2 () 的調(diào)用方來說，缺乏背景去理解、且業(yè)務(wù)概念上無關(guān)，我們可以將它重新包裝成調(diào)用方可以理解的新異常，然后 re-throw。

應(yīng)該選擇上面的哪種處理方式，總結(jié)來說就是從以下兩個方面進行判斷：

• 函數(shù) 1 拋出的異常是否可以恢復(fù)
• 函數(shù) 1 拋出的異常對于 函數(shù) 2 的調(diào)用方來說是否可以理解、關(guān)心、業(yè)務(wù)概念相關(guān)

總之，是否往上繼續(xù)拋出，要看上層代碼是否關(guān)心這個異常。關(guān)心就將它拋出，否則就直接吞掉。 是否需要包裝成新的異常拋出，看上層代碼是否能理解這個異常、是否業(yè)務(wù)相關(guān)。如果能理解、業(yè)務(wù)相關(guān)就可以直接拋出，否則就封裝成新的異常拋出。

對于處理函數(shù)拋出的異常，我們需要注意：

• 如果選擇吞掉函數(shù)拋出的異常的話，我們必須把異常輸出到日志系統(tǒng)，方便后續(xù)診斷。
• 如果把異常輸出到日志系統(tǒng)時，我們在保證診斷信息足夠的同時，也要考慮避免包含敏感信息，因為那樣可能導(dǎo)致潛在的安全問題。

如果我們看 Java 的標準類庫，你可能注意到類似 java.net.ConnectException，出錯信息是類似 “Connection refused (Connection refused)”，而不包含具體的機器名、IP、端口等，一個重要考量就是信息安全。 類似的情況在日志中也有，比如，用戶數(shù)據(jù)一般是不可以輸出到日志里面的。

受檢異常 or 非受檢異常

在函數(shù)拋出異常的時候，如果選擇向上拋出，我們應(yīng)該選擇拋出哪種類型的異常呢？是受檢異常還是非受檢異常？

對于代碼 bug（比如下標訪問越界、空指針）以及不可恢復(fù)的異常（比如數(shù)據(jù)庫連接失敗），即便我們捕獲了，也做不了太多事情，我們希望程序能 fail-fast，所以，我們傾向于使用非受檢異常，將程序終止掉。 對于可恢復(fù)異常、業(yè)務(wù)異常，比如提現(xiàn)金額大于余額的異常，我們更傾向于使用受檢異常，明確告知調(diào)用者需要捕獲處理。

處理異常的原則

盡量不要捕獲通用異常

盡量不要捕獲類似 Exception 這樣的通用異常，而應(yīng)該捕獲特定異常（盡量縮小捕獲的異常范圍）。

下面舉例說明，實例代碼如下：

try {
    // 業(yè)務(wù)代碼
    // …
    Thread.sleep(1000L);
} catch (Exception e) {
    // Ignore it
}

對于 Thread.sleep () 函數(shù)拋出的 InterruptedException，我們不應(yīng)該捕獲 Exception 通用異常，而應(yīng)該捕獲 InterruptedException 這樣的特定異常。

這是因為我們要保證程序不會捕獲到我們不希望捕獲的異常。比如，我們更希望 RuntimeException 導(dǎo)致線程終止，而不是被捕獲。

不要生吞異常

不要生吞（swallow）異常，盡量把異常信息記錄到日志系統(tǒng)中。 這是異常處理中要特別注意的事情，因為生吞異常很可能會導(dǎo)致難以診斷的詭異情況。 如果我們沒有把異常拋出，也沒有把異常記錄到日志系統(tǒng)，程序可能會在后續(xù)出現(xiàn)難以排查的 bug。沒人能夠輕易判斷究竟是哪里拋出了異常，以及是什么原因產(chǎn)生了異常。

再來看一段代碼：

try {
    // 業(yè)務(wù)代碼
    // …
} catch (IOException e) {
    e.printStackTrace();
}

這段代碼作為一段實驗代碼，是沒有任何問題的，但是在產(chǎn)品代碼中，通常都不允許這樣處理。 你先思考一下這是為什么呢？ 我們先來看看 printStackTrace () 的文檔，開頭就是 “Prints this throwable and its backtrace to the standard error stream”。問題就在這里，在稍微復(fù)雜一點的生產(chǎn)系統(tǒng)中，標準出錯（STERR）不是個合適的輸出選項，因為你很難判到底輸出到哪里去了。尤其是對于分布式系統(tǒng)，如果發(fā)生異常，但是無法找到堆棧軌跡（stacktrace），這純屬是為診斷設(shè)置障礙。 所以，最好使用產(chǎn)品日志，詳細地將異常記錄到日志系統(tǒng)里。

異常處理時，性能開銷大的地方

我們從性能角度來審視一下 Java 的異常處理機制，這里有兩個性能開銷相對大的地方：

• try-catch 代碼段會產(chǎn)生額外的性能開銷，或者換個角度說，它往往會影響 JVM 對代碼進行優(yōu)化，所以建議僅捕獲有必要的代碼段，盡量不要一個大的 try 包住整段的代碼；
• Java 每實例化一個 Exception，都會對當時的棧進行快照，這是一個相對比較重的操作。如果實例化 Exception 發(fā)生的非常頻繁，這個開銷可就不能被忽略了。

當我們的服務(wù)出現(xiàn)反應(yīng)變慢、吞吐量下降的時候，檢查發(fā)生最頻繁的 Exception 也是一種思路。

到此這篇關(guān)于Java 中的異常處理機制詳情介紹的文章就介紹到這了,更多相關(guān)Java 異常處理內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論