概念 異常處理的概念起源於早期的編程語言,如 LISP、PL/I 和 CLU。這些編程語言首次引入了異常處理機制,以便在程式執行過程中檢測和處理錯誤情況。異常處理機制隨後在 Ada、Modula-3、C++、Python、Java 等編程語言中得到了廣泛採用和發展。在 Java 中,異常處理是提供一 ...
概念
異常處理的概念起源於早期的編程語言,如 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 語言追求簡潔、高效的目標相一致。
陳述總結
最後,關於檢查型異常在某些場景下可以提高代碼的可靠性和健壯性,但在另一些場景下可能導致代碼冗餘和難以維護。在很多人看來弊大於利了。然而,這並不意味著在所有情況下都不應該使用檢查型異常。在某些場景下,合理地使用檢查型異常可以幫助提高代碼的健壯性和可靠性。關鍵是要明確異常處理的目的,在實際開發中,可以根據需要和團隊的編碼規範來權衡使用檢查型異常。