概念
例外處理的概念起源于早期的編程語言，如 LISP、PL/I 和 CLU，這些編程語言首次引入了例外處理機制，以便在程式執行程序中檢測和處理錯誤情況，例外處理機制隨后在 Ada、Modula-3、C++、Python、Java 等編程語言中得到了廣泛采用和發展，在 Java 中，例外處理是提供一種在程式運行時處理錯誤和例外情況的方法，例外處理機制使得程式能夠在遇到錯誤時繼續執行，而不是立即崩潰，這種機制使程式更具有健壯性和容錯性，例外分為兩類：受檢例外（Checked Exceptions）和非受檢例外（Unchecked Exceptions）
受檢例外（Checked Exceptions）：
受檢例外是指那些在編譯時必須處理的例外，它們通常是由程式員的錯誤或外部資源問題引起的，例如，IOException、FileNotFoundException 等，受檢例外必須在方法簽名中使用 throws 關鍵字宣告，或者在方法體內用 try-catch 塊捕獲和處理，
非受檢例外（Unchecked Exceptions）：
非受檢例外是指那些在編譯時不強制要求處理的例外，它們通常是由編程錯誤引起的，如空指標例外（NullPointerException）、陣列越界（ArrayIndexOutOfBoundsException）等，非受檢例外繼承自 java.lang.RuntimeException 類，不需要在方法簽名中宣告，也不需要強制捕獲和處理，
它們的關系如下：
classDiagram class Throwable { +getMessage(): String +printStackTrace(): void } class Error { } class AssertionError{ } class VirtualMachineError{ } class Exception { } class RuntimeException { } class IOException { } class FileNotFoundException { } class NullPointerException { } class IndexOutOfBoundsException { } Throwable <|-- Error Throwable <|-- Exception Error <|-- AssertionError Error <|-- VirtualMachineError Exception <|-- RuntimeException Exception <|-- IOException IOException <|-- FileNotFoundException RuntimeException <|-- NullPointerException RuntimeException <|-- IndexOutOfBoundsException例外處理
Java 使用 try/catch 關鍵字進行例外捕獲，使用 throw 宣告拋出例外，示例代碼如下：
public class NullPointerExceptionExample {
public static void main(String[] args) {
String nullString = null;
try {
int length = nullString.length();
} catch (NullPointerException e) {
System.out.println("Caught NullPointerException!");
e.printStackTrace();
}
}
}
在這個示例中，我們嘗試獲取一個 null 字串的長度，當呼叫 nullString.length() 時，會拋出 NullPointerException，我們使用 try-catch 陳述句捕獲例外并處理它
自定義例外
Java 官方例外不可能預見所有可能發生的錯誤，有時候你需要結合自己的業務場景，例如以下場景：
- 當內置的 Java 例外類無法準確描述你所遇到的例外情況時，
- 需要為特定領域或業務邏輯創建一組特定的例外，
- 當希望通過自定義例外類向呼叫者提供更多的背景關系資訊或特定的錯誤代碼時，
構建特定的例外，這也很簡單，繼承已有的例外類（最好繼承含義差不多的），如下，我們創建一個表示賬戶余額不足的例外：
public class InsufficientBalanceException extends RuntimeException {
private double balance;
private double amount;
public InsufficientBalanceException(double balance, double amount) {
super("Insufficient balance: " + balance + ", required amount: " + amount);
this.balance = balance;
this.amount = amount;
}
public double getBalance() {
return balance;
}
public double getAmount() {
return amount;
}
}
接下來，我們在業務邏輯代碼中使用這個自定義例外：
public class BankAccount {
private double balance;
public BankAccount(double balance) {
this.balance = balance;
}
public void withdraw(double amount) throws InsufficientBalanceException {
if (amount > balance) {
throw new InsufficientBalanceException(balance, amount);
}
balance -= amount;
}
}
呼叫者可以捕獲并處理這個自定義例外：
public class BankAccountTest {
private static final Logger logger = Logger.getLogger(BankAccountTest.class.getName());
public static void main(String[] args) {
BankAccount account = new BankAccount(1000.00);
try {
account.withdraw(2000.00);
} catch (InsufficientBalanceException e) {
System.out.println("Error: " + e.getMessage());
System.out.println("Current balance: " + e.getBalance());
System.out.println("Required amount: " + e.getAmount());
logger.log(Level.SEVERE, "An exception occurred", e);
}
}
}
可以看到自定義例外使我們能夠更清晰地表達業務邏輯中可能出現的例外情況，同時為呼叫者提供更多關于例外的背景關系資訊，我們還使用 java.util.logging 工具將輸出記錄到日志中
多重捕獲
在 Java 早起版本，處理多個沒有共同基類的例外，需要為每一個例外型別撰寫一個 catch 陳述句處理，如下：
class CustomException1 extends Exception {
public CustomException1(String message) {
super(message);
}
}
class CustomException2 extends Exception {
public CustomException2(String message) {
super(message);
}
}
public class SingleCatchException {
public static void main(String[] args) {
try {
// 根據引數選擇拋出哪種例外
if (args.length > 0 && "type1".equals(args[0])) {
throw new CustomException1("This is a custom exception type 1.");
} else {
throw new CustomException2("This is a custom exception type 2.");
}
} catch (CustomException1 e) {
// 當 CustomException1 發生時，執行此代碼塊
System.err.println("Error occurred: " + e.getMessage());
} catch (CustomException2 e) {
// 當 CustomException2 發生時，執行此代碼塊
System.err.println("Error occurred: " + e.getMessage());
}
}
}
這樣的代碼不僅難以閱讀，而且也不夠簡潔，
多重例外捕獲機制，它允許在一個 catch 陳述句中捕獲多個例外型別，這種方法可以避免重復的代碼，使例外處理更加簡潔，以下是一個使用多重例外捕獲機制的示例：
public class MultiCatchExample {
public static void main(String[] args) {
try {
// 根據引數選擇拋出哪種例外
if (args.length > 0 && "type1".equals(args[0])) {
throw new CustomException1("This is a custom exception type 1.");
} else {
throw new CustomException2("This is a custom exception type 2.");
}
} catch (CustomException1 | CustomException2 e) {
// 當 CustomExceptionType1 或 CustomExceptionType2 發生時，執行此代碼塊
System.err.println("Error occurred: " + e.getMessage());
}
}
}
重新拋出例外
在某些情況下，你可能希望將例外傳遞給呼叫者處理，而不是在當前方法中處理，或者需要在捕獲例外時執行一些處理操作，如記錄日志、清理資源或者添加額外的背景關系資訊，在這種情況下，你可以在 catch 塊中處理例外，然后重新拋出原始例外或拋出一個新的例外，包含額外的資訊，如下：
public class RethrowExceptionExample {
public static void main(String[] args) {
try {
doSomething(); // 可能會拋出例外的方法
} catch (IOException e) {
// 例外處理邏輯
System.err.println("An error occurred: " + e.getMessage());
// 重新拋出例外
throw e;
}
}
}
更好的 NPE
NPE（NullPointerExceptions）是很常見例外，在 JDK 14 以前遇到 NPE 例外，能得到資訊有限，JDK 15 引入了一項名為“Helpful NullPointerExceptions”的新功能，這項功能改進了 NullPointerException (NPE) 的診斷，在之前的 JDK 版本中，當發生 NullPointerException 時，例外資訊通常并不提供足夠的背景關系來幫助開發人員定位問題的具體位置，
示例代碼：
class A {
String s;
public A(String s) {
this.s = s;
}
}
class B {
A a;
public B(A a) {
this.a = a;
}
}
class C {
B b;
public C(B b) {
this.b = b;
}
}
public class BetterNullPointerReports {
public static void main(String[] args) {
C[] ca = {
new C(new B(new A(null))),
new C(new B(null)),
new C(null)
};
for (C c : ca) {
try {
System.out.println(c.b.a.s);
} catch (NullPointerException npe) {
System.out.println(npe);
}
}
}
}
在 JDK 14 及之前的版本中，輸出結果：
# 你根本看不出哪里出了問題
null
java.lang.NullPointerException
java.lang.NullPointerException
在 JDK 15 及之后的版本中，輸出結果：
# 得到更詳細的 NPE 資訊
null
java.lang.NullPointerException: Cannot read field "s" because "c.b.a" is null
java.lang.NullPointerException: Cannot read field "a" because "c.b" is null
清道夫：finally
當程式發生了非預期的例外，那么程式會終止運行，但是對于很多需要執行清理操作，這是不可接受的，例如：
- 關閉資源：在
try塊中打開的資源，如檔案、資料庫連接、網路連接等，需要在完成操作后確保被正確關閉 - 釋放鎖：在并發編程中，可能會使用鎖來同步代碼，在釋放鎖之前，如果發生例外，可能會導致其他執行緒無法獲取鎖
- 回滾事務：在資料庫編程中，可能需要在事務中執行一系列操作，如果這些操作中的任何一個失敗，事務需要回滾
- 恢復狀態：在執行某些操作時，可能需要更改物件或系統的狀態，在操作完成后，可能需要恢復原始狀態
對于以上的程式來說，finally 就非常重要了，它可以解決以上程式的清理操作，
示例代碼：
import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;
public class FinallyExample {
public static void main(String[] args) {
BufferedReader reader = null;
try {
reader = new BufferedReader(new FileReader("example.txt"));
String line;
while ((line = reader.readLine()) != null) {
System.out.println(line);
}
} catch (IOException e) {
System.err.println("Error reading file: " + e.getMessage());
} finally {
if (reader != null) {
try {
reader.close();
} catch (IOException e) {
System.err.println("Error closing file: " + e.getMessage());
}
}
}
}
}
在以上代碼中，無論程式是否出錯，finally 都可以確保檔案被正確關閉
例外的約束
Java 在面向物件中對例外存在頗多約束和限制，其主要目的如下：
- 保持子型別可替換性：當子類覆寫父類的方法或實作介面的方法時，子類的方法應該滿足父類或介面方法的約定
- 避免意外的例外：如果子類方法可以拋出任意例外，那么呼叫者在處理例外時可能遇到意外的例外型別，導致程式出錯
- 提高代碼可讀性：通過限制例外的繼承和實作規則，可以使得代碼更加清晰和易于理解
- 促進良好的設計實踐：如果子類方法可以拋出任意例外，那么程式員可能會過度依賴例外來處理錯誤情況，導致代碼難以維護
在介面和繼承中使用例外，需要遵循以下規則：
- 子類可以拋出與介面或者父類方法相同的例外，
- 子類可以不拋出任何例外，即使介面或父類方法宣告了例外，這意味著實作類的方法已經處理了這些例外，
- 子類可以拋出介面方法或父類宣告例外的相同型別的例外，因為子類例外依然符合介面方法的約定，
代碼示例：
class CustomException extends RuntimeException {}
class CustomExceptionChild extends CustomException {}
interface MyInterface {
void myMethod() throws CustomException;
}
class MyClass1 implements MyInterface {
// 1：拋出與介面方法相同例外
@Override
// public void myMethod() throws FileNotFoundException { // 編譯錯誤，不能拋出不同型別的例外
public void myMethod() throws CustomException {
// ...
}
}
class MyClass2 implements MyInterface {
// 2：即使不拋出任何例外，也沒有問題
@Override
public void myMethod() {
}
}
class MyClass3 implements MyInterface {
// 3: 拋出介面方法宣告例外的子類例外（或者父類，既相同型別即可）
@Override
public void myMethod() throws CustomExceptionChild {
// ...
}
}
try-with-resources
在 Java 7 中，關于自動管理資源，在處理需要關閉的資源（如檔案、資料庫連接、網路連接等）有了更好的選擇，那就是使用 try-catch-finally 進行處理，它對比 finally 具有以下優勢：
- 簡化代碼：相比
finally顯示關閉資源，使用 Try-With-Resources，可以自動關閉資源，從而使代碼更簡潔、易讀， - 避免資源泄漏：使用 Try-With-Resources 能夠確保在退出
try代碼塊時自動關閉資源，降低資源泄漏的風險， - 減少錯誤：Try-With-Resources 能夠正確地處理資源關閉程序中的例外，并提供完整的例外資訊，有助于減少錯誤，
示例代碼：
import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;
public class TryWithResourcesExample {
public static void main(String[] args) {
String fileName = "example.txt";
try (BufferedReader reader = new BufferedReader(new FileReader(fileName))) {
String line;
while ((line = reader.readLine()) != null) {
System.out.println(line);
}
} catch (IOException e) {
System.err.println("Error reading file: " + e.getMessage());
}
}
}
在這個示例中，我們使用 Try-With-Resources 陳述句創建了一個 BufferedReader 實體，BufferedReader 實作了 Closeable 介面，因此在退出 try 代碼塊時，reader 會自動呼叫 close() 方法以釋放資源，
為了一探 Try-With-Resources 的究竟，我們可以創建自定義的 AutoCloseable 類：
class Reporter implements AutoCloseable {
String name = getClass().getSimpleName();
public Reporter() {
System.out.println("Creating " + name);
}
@Override
public void close() throws Exception {
System.out.println("Closing " + name);
}
}
class First extends Reporter {}
class Second extends Reporter {}
public class AutoCloseableDetails {
public static void main(String[] args) {
try (First f = new First(); Second s = new Second()) {
System.out.println("In body");
} catch (Exception e) {
System.out.println("Exception caught");
}
}
}
輸出結果：
Creating First
Creating Second
In body
Closing Second
Closing First
退出 try 塊會呼叫兩個物件的 close() 方法，并以與創建順序相反的順序關閉它們，（順序很重要），
使用 Try-With-Resource 是很安全的，假設你隨意在 Try 頭使用物件，會出現編譯錯誤：
class Anything {}
public class TryAnything {
public static void main(String[] args) {
// 假設我們定義的類，不是 AutoCloseable 的物件，會出現編譯錯誤
try (Anything a = new Anything()) { // compile error
System.out.println("In body");
} catch (Exception e) {
System.out.println("Exception caught");
}
}
}
例外型別匹配
Java 在拋出例外時，會根據例外型別進行匹配，例外處理程式會從上到下依次檢查 catch 子句，看它們是否與拋出的例外型別兼容，當發現兼容的 catch 子句時，Java 就會執行該子句的代碼來處理例外，請注意，Java 只會執行與拋出例外型別兼容的第一個 catch 子句，
示例代碼：
public class ExceptionMatchingExample {
public static void main(String[] args) {
try {
// ... Some code that may throw exceptions ...
throw new FileNotFoundException("File not found");
} catch (FileNotFoundException e) {
System.out.println("Handling FileNotFoundException: " + e.getMessage());
} catch (IOException e) {
System.out.println("Handling IOException: " + e.getMessage());
} catch (Exception e) {
System.out.println("Handling general exception: " + e.getMessage());
}
}
}
在這個示例中，我們拋出了一個 FileNotFoundException，Java 會從上到下檢查 catch 子句，看它們是否與 FileNotFoundException 兼容，因為 FileNotFoundException 是 IOException 的子類，它與 FileNotFoundException 和 IOException 的 catch 子句兼容，但是，Java 只會執行第一個兼容的 catch 子句，即 FileNotFoundException 子句，如果沒有找到兼容的 catch 子句，Java 會繼續在呼叫堆疊中查找例外處理程式，直到找到一個合適的處理程式或者程式終止，
輸出結果：
Handling FileNotFoundException: File not found
使用指南
例外看似簡單易懂，但在處理程序中還需要遵循許多最佳實踐，例如：
- 除非你知道如何處理，否則不要捕獲例外（錯誤處理代碼太多，容易干擾主線代碼的邏輯和可讀性）
- 不要生吞例外：捕獲例外不進行處理會導致例外消失，從而對于線上問題排查，無從下手
- 捕獲具體例外：盡量捕獲具體的例外類，而不是捕獲泛化的 Exception 類
- 盡可能的使用多重例外捕獲來簡化重復代碼，并且提高代碼的可讀性
- 盡可能的使用 Try-With-Resources 清理資源
- 自定義例外：在需要時，為特定于你的應用程式的例外情況創建自定義例外
檢查型例外是 shit ?
檢查型例外（checked exceptions）在 Java 中引發了很多爭議，有些人認為它們是一種有益的設計，可以提高代碼的可靠性，而另一些人則認為它們是一種糟糕的設計，會導致代碼冗余和難以維護，例如 Martin Fowler （《UML 精粹》、《重構》）作者，也曾在博客發表稱：
總的來說，我認為例外很不錯，但是 Java 的檢查型例外要比好處多
那么檢查型例外究竟帶來了什么問題 ？ 常見的槽點有：
- 強制錯誤處理：檢查型例外強制開發者處理例外情況，導致主線代碼中充斥著大量和業務邏輯無關的代碼
- 代碼冗余：檢查型例外可能導致大量的 try-catch 代碼塊，增加代碼冗余，影響代碼可讀性
- 例外傳遞：對于一些需要在多層方法呼叫中傳遞例外的情況，檢查型例外可能導致開發者不得不為每個方法添加例外宣告
Go 也沒有例外啊
最幾年 Go 語言的成功讓很多人加深了這一觀點，Go 語言沒有檢查型例外的概念，但它們的代碼依然可以具有很高的可靠性，這表明檢查型例外并非是提高代碼可靠性的唯一方法，Go 語言的設計者們有意避免了引入檢查型例外，主要有以下原因：
- 代碼簡潔性：Go 語言的設計者們希望保持代碼簡潔，避免因為例外處理而產生的大量冗余代碼，
- 顯示錯誤處理：Go 語言鼓勵開發者顯式地處理錯誤，而不是通過例外機制隱式地處理，
- 降低復雜性：例外機制會增加程式的復雜性，Go 語言的設計者們希望通過避免引入例外機制，讓程式更簡單易懂，
- 性能開銷：例外處理機制可能會帶來一定的性能開銷，通過回傳 error 型別，可以避免這種性能開銷，
示例代碼：
package main
import (
"errors"
"fmt"
)
func divide(a, b int) (int, error) {
if b == 0 {
return 0, errors.New("division by zero")
}
return a / b, nil
}
func main() {
result, err := divide(10, 2)
if err != nil {
fmt.Println("Error:", err)
} else {
fmt.Println("Result:", result)
}
result, err = divide(10, 0)
if err != nil {
fmt.Println("Error:", err)
} else {
fmt.Println("Result:", result)
}
}
在這個示例中，我們定義了一個名為divide的函式，它接受兩個整數引數a和b，計算它們的商，如果b為零，函式將回傳一個非空的error型別值，以指示發生了錯誤，否則，函式將回傳商和一個空error值，在 main 函式中，我們呼叫divide兩次，一次使用一個非零除數，另一次使用零作為除數，對于第一次呼叫，divide將回傳一個空的error值，我們就可以列印出計算結果，對于第二次呼叫，divide將回傳一個非空的error值，我們使用if err != nil來檢查這個值是否為nil，如果不是，就列印錯誤資訊，
輸出結果：
Result: 5
Error: division by zero
以上就是 Go 在處理例外的方式，盡管 Go 語言沒有引入檢查型例外，但它依然具備了一套有效的錯誤處理機制，使用多值回傳（value, error）的方式，可以讓代碼更簡潔、易讀，同時鼓勵開發者顯式地處理錯誤，這種設計理念與 Go 語言追求簡潔、高效的目標相一致，
陳述總結
最后，關于檢查型例外在某些場景下可以提高代碼的可靠性和健壯性，但在另一些場景下可能導致代碼冗余和難以維護，在很多人看來弊大于利了，然而，這并不意味著在所有情況下都不應該使用檢查型例外，在某些場景下，合理地使用檢查型例外可以幫助提高代碼的健壯性和可靠性，關鍵是要明確例外處理的目的，在實際開發中，可以根據需要和團隊的編碼規范來權衡使用檢查型例外，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/549544.html
標籤：Java
上一篇：java -- 練習題