例外処理の概念は、LISP、PL/I、CLU などの初期のプログラミング言語で生まれました。これらのプログラミング言語には、プログラム実行中にエラー状態を検出して処理するための例外処理メカニズムが初めて導入されました。例外処理メカニズムはその後、Ada、Modula-3、C、Python、Java などのプログラミング言語で広く採用され、開発されました。 Java では、例外処理により、プログラムの実行中にエラーと例外を処理する方法が提供されます。例外処理メカニズムにより、プログラムはエラーが発生してもすぐにクラッシュするのではなく、実行を継続できます。このメカニズムにより、プログラムの堅牢性と耐障害性が高まります。例外は、チェック済み例外と未チェック例外の 2 つのカテゴリに分類されます。
チェック済み例外:
チェック済み例外は、コンパイル時に処理する必要がある例外です。これらは通常、プログラマーのエラーまたは外部リソースの問題によって発生します。たとえば、IOException
、FileNotFoundException
などです。チェック例外は、メソッド シグネチャの throws
キーワードを使用して宣言するか、メソッド本体内で try-catch
ブロックを使用してキャプチャして処理する必要があります。
未チェック例外:
未チェック例外とは、コンパイル時に処理する必要のない例外を指します。これらは通常、ヌル ポインター例外 (NullPointerException
)、配列の範囲外 (ArrayIndexOutOfBoundsException
) などのプログラミング エラーによって発生します。未チェック例外は java.lang.RuntimeException
クラスから継承され、メソッド シグネチャで宣言する必要はなく、強制的にキャプチャして処理する必要もありません。
これらの関係は次のとおりです。
Java は try/catch
キーワードを使用してキャッチします。例外を宣言するには、throw
を使用します。サンプル コードは次のとおりです。
1 2 3 4 5 6 7 8 9 10 11 |
|
この例では、null
文字列の長さを取得しようとします。 nullString.length()
が呼び出されると、NullPointerException
がスローされます。 try-catch
ステートメントを使用して例外をキャッチし、処理します
Java 公式例外では、考えられるすべてのエラーを予測することはできません。場合によっては、独自の例外を組み合わせる必要がある場合があります。次のようなビジネス シナリオ:
組み込み Java 例外クラスが、発生した異常な状況を正確に説明できない場合。
特定のドメインまたはビジネス ロジックに対して、特定の例外セットを作成する必要があります。
カスタム例外クラスを通じて、より多くのコンテキスト情報や特定のエラー コードを呼び出し元に提供したい場合。
特定の例外の構築も非常に簡単です。既存の例外クラスを継承します (同じ意味を継承するのが最善です)。次のように、口座残高不足を示す例外を作成します:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
次に、ビジネス ロジック コードでこのカスタム例外を使用します:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
呼び出し元はこのカスタム例外をキャッチして処理できます:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
カスタム例外の定義を確認できます。例外を使用すると、ビジネス ロジックで起こり得る例外をより明確に表現できると同時に、呼び出し元に例外に関するコンテキスト情報をより多く提供できます。また、java.util.logging
ツールを使用して出力をログに記録します。
Java の初期のバージョンでは、共通点のない複数の例外を処理します。基本クラスの場合、次のように例外タイプごとに catch ステートメントを記述する必要があります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
|
このようなコードは読みにくいだけでなく、十分に簡潔でもありません。
複数の例外キャッチ メカニズム。1 つの catch
ステートメントで複数の例外タイプをキャッチできます。このアプローチにより、コードの重複が回避され、例外処理がより簡潔になります。以下は、複数の例外キャッチ メカニズムを使用する例です。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
場合によっては、現在のメソッド内ではなく、処理のために呼び出し元に例外を渡したい場合があります。処理。または、例外をキャッチするときに、ログ記録、リソースのクリーンアップ、追加のコンテキスト情報の追加など、いくつかの処理操作を実行する必要があります。この場合、次のように、catch
ブロックで例外を処理し、元の例外を再スローするか、追加情報を含む新しい例外をスローすることができます。
1 2 3 4 5 6 7 8 9 10 11 12 |
|
NPE (NullPointerExceptions) は非常に一般的な例外です。JDK 14 より前では、NPE 例外が発生した場合に入手できる情報は限られていました。JDK 15 では、「Helpful NullPointerExceptions」と呼ばれる新機能が導入されました。この機能により、NullPointerException (NPE) 診断が改善されました。以前の JDK バージョンでは、NullPointerException が発生した場合、開発者が問題の特定の場所を特定するのに役立つ十分なコンテキストが例外情報から提供されないことがよくありました。
サンプル コード:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
|
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
当程序发生了非预期的异常,那么程序会终止运行,但是对于很多需要执行清理操作,这是不可接受的,例如:
关闭资源:在 try
块中打开的资源,如文件、数据库连接、网络连接等,需要在完成操作后确保被正确关闭
释放锁:在并发编程中,可能会使用锁来同步代码。在释放锁之前,如果发生异常,可能会导致其他线程无法获取锁
回滚事务:在数据库编程中,可能需要在事务中执行一系列操作。如果这些操作中的任何一个失败,事务需要回滚
恢复状态:在执行某些操作时,可能需要更改对象或系统的状态。在操作完成后,可能需要恢复原始状态
对于以上的程序来说,finally 就非常重要了,它可以解决以上程序的清理操作。
示例代码:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
|
在以上代码中,无论程序是否出错,finally
都可以确保文件被正确关闭
Java 在面向对象中对异常存在颇多约束和限制,其主要目的如下:
保持子类型可替换性:当子类覆盖父类的方法或实现接口的方法时,子类的方法应该满足父类或接口方法的约定
避免意外的异常:如果子类方法可以抛出任意异常,那么调用者在处理异常时可能遇到意外的异常类型,导致程序出错
提高代码可读性:通过限制异常的继承和实现规则,可以使得代码更加清晰和易于理解
促进良好的设计实践:如果子类方法可以抛出任意异常,那么程序员可能会过度依赖异常来处理错误情况,导致代码难以维护
在接口和继承中使用异常,需要遵循以下规则:
子类可以抛出与接口或者父类方法相同的异常。
子类可以不抛出任何异常,即使接口或父类方法声明了异常。这意味着实现类的方法已经处理了这些异常。
子类可以抛出接口方法或父类声明异常的相同类型的异常,因为子类异常依然符合接口方法的约定。
代码示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
|
在 Java 7 中,关于自动管理资源。在处理需要关闭的资源(如文件、数据库连接、网络连接等)有了更好的选择,那就是使用 try-catch-finally
进行处理,它对比 finally
具有以下优势:
简化代码:相比 finally
显示关闭资源,使用 Try-With-Resources,可以自动关闭资源,从而使代码更简洁、易读。
避免资源泄漏:使用 Try-With-Resources 能够确保在退出 try
代码块时自动关闭资源,降低资源泄漏的风险。
减少错误:Try-With-Resources 能够正确地处理资源关闭过程中的异常,并提供完整的异常信息,有助于减少错误。
示例代码:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
在这个示例中,我们使用 Try-With-Resources 语句创建了一个 BufferedReader
实例。BufferedReader
实现了 Closeable
接口,因此在退出 try
代码块时,reader
会自动调用 close()
方法以释放资源。
为了一探 Try-With-Resources 的究竟,我们可以创建自定义的 AutoCloseable
类:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
输出结果:
Creating First
Creating Second
In body
Closing Second
Closing First
退出 try 块会调用两个对象的 close() 方法,并以与创建顺序相反的顺序关闭它们。(顺序很重要)。
使用 Try-With-Resource 是很安全的,假设你随意在 Try 头使用对象,会出现编译错误:
1 2 3 4 5 6 7 8 9 10 11 12 |
|
Java 在抛出异常时,会根据异常类型进行匹配。异常处理程序会从上到下依次检查 catch
子句,看它们是否与抛出的异常类型兼容。当发现兼容的 catch
子句时,Java 就会执行该子句的代码来处理异常。请注意,Java 只会执行与抛出异常类型兼容的第一个 catch
子句。
示例代码:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
在这个示例中,我们抛出了一个 FileNotFoundException
,Java 会从上到下检查 catch
子句,看它们是否与 FileNotFoundException
兼容。因为 FileNotFoundException
是 IOException
的子类,它与 FileNotFoundException
和 IOException
的 catch
子句兼容。但是,Java 只会执行第一个兼容的 catch
子句,即 FileNotFoundException
子句。如果没有找到兼容的 catch
子句,Java 会继续在调用栈中查找异常处理程序,直到找到一个合适的处理程序或者程序终止。
输出结果:
Handling FileNotFoundException: File not found
异常看似简单易懂,但在处理过程中还需要遵循许多最佳实践,例如:
除非你知道如何处理,否则不要捕获异常(错误处理代码太多,容易干扰主线代码的逻辑和可读性)
不要生吞异常:捕获异常不进行处理会导致异常消失,从而对于线上问题排查,无从下手
捕获具体异常:尽量捕获具体的异常类,而不是捕获泛化的 Exception 类
尽可能的使用多重异常捕获来简化重复代码,并且提高代码的可读性
尽可能的使用 Try-With-Resources 清理资源
自定义异常:在需要时,为特定于你的应用程序的异常情况创建自定义异常
检查型异常(checked exceptions)在 Java 中引发了很多争议。有些人认为它们是一种有益的设计,可以提高代码的可靠性,而另一些人则认为它们是一种糟糕的设计,会导致代码冗余和难以维护,例如 Martin Fowler (《UML 精粹》、《重构》)作者,也曾在博客发表称:
总的来说,我认为异常很不错,但是 Java 的检查型异常要比好处多
那么检查型异常究竟带来了什么问题 ? 常见的槽点有:
强制错误处理:检查型异常强制开发者处理异常情况,导致主线代码中充斥着大量和业务逻辑无关的代码
代码冗余:检查型异常可能导致大量的 try-catch 代码块,增加代码冗余,影响代码可读性
异常传递:对于一些需要在多层方法调用中传递异常的情况,检查型异常可能导致开发者不得不为每个方法添加异常声明
最几年 Go 语言的成功让很多人加深了这一观点,Go 语言没有检查型异常的概念,但它们的代码依然可以具有很高的可靠性。这表明检查型异常并非是提高代码可靠性的唯一方法。Go 语言的设计者们有意避免了引入检查型异常,主要有以下原因:
代码简洁性:Go 语言的设计者们希望保持代码简洁,避免因为异常处理而产生的大量冗余代码。
显示错误处理:Go 语言鼓励开发者显式地处理错误,而不是通过异常机制隐式地处理。
降低复杂性:异常机制会增加程序的复杂性。Go 语言的设计者们希望通过避免引入异常机制,让程序更简单易懂。
性能开销:异常处理机制可能会带来一定的性能开销,通过返回 error 类型,可以避免这种性能开销。
示例代码:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
|
在这个示例中,我们定义了一个名为divide
的函数,它接受两个整数参数a
和b
,计算它们的商。如果b
为零,函数将返回一个非空的error
类型值,以指示发生了错误。否则,函数将返回商和一个空error
值。在 main
函数中,我们调用divide
两次,一次使用一个非零除数,另一次使用零作为除数。对于第一次调用,divide
将返回一个空的error
值,我们就可以打印出计算结果。对于第二次调用,divide
将返回一个非空的error
值,我们使用if err != nil
来检查这个值是否为nil
,如果不是,就打印错误信息。
输出结果:
Result: 5
Error: division by zero
以上がJava例外処理メカニズムを使用するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。