最近、例外に関する多くの投稿を読んでいますが、チェックされていない例外をキャッチする必要があるかどうか疑問があります。アプリケーションをエラーから回復させたい場合は、チェックされた例外を使用することを読みました。ただし、チェックされた例外を処理できない場合は、別のチェックされた例外にラップして、別のレイヤーに渡すことができます。たとえば、をラップしSqlExceptionたり、チェックされていない例外をスローしたりします。ただし、チェックされていない例外をキャッチする必要がありますか？チェックされていない例外は、理想的にはチェックしていないプログラミングエラーですか？それらはあなたのアプリケーションからただ泡立つべきですか？
3556 次
6 に答える
9
チェックされていない例外をキャッチして処理する必要がありますか？
答えはそれが依存するということです：
例外が何であるかによって異なります。
例外がスローされた理由によって異なります。それは「期待された」でしたか？それはバグ、悪い入力、または環境問題によるものでしたか？または、他の何か？
回復する良い方法があるかどうかによって異なります。これは通常、前の基準に部分的に依存します。
例外が予期しないものである場合、例外の原因が不明である場合、および/または例外をキャッチした場合に適切な回復戦略がない場合は、通常、例外をバブルアップさせて、確実に発生するようにすることをお勧めします。トップレベルで報告/ログに記録されます。
また、例外がであるError場合、一般的なルールは、回復を試みてはならないということです。そして、それはStackOverflowErrorと（特に）を含みOutOfMemoryErrorます。例外は、安全に回復するのErrorが難しい（または不可能な）問題を示しており、最善の戦略は、アプリケーションを終了させるか、終了させることです。
トップレベルで報告/ログに記録されるとはどういう意味ですか？たとえば、UIレイヤーでそれをキャッチし、ダイアログを表示したり、ログに記録したりすることを意味しますか？
つまり、例外とそのスタックトレースをアプリケーションのログファイルに書き込んで、メンテナが問題の証拠を確認できるようにする必要があります。問題をエンドユーザーに説明しようとするかどうか（およびその方法）は、別の問題です。
「トップレベル」は、「メイン」メソッド、子スレッド、ランナブルの「実行」メソッド、またはキャッチされない例外ハンドラーの場合があります。基本的には、例外がキャッチされない場合に最終的に「バブルアップ」する場所です。詳細は、アプリケーションのアーキテクチャによって異なります。
于 2012-11-06T12:49:19.507 に答える
5
問題から回復するために意味のある方法で例外を処理できる場合は、例外（チェックされているかどうかに関係なく）をキャッチする必要があります。例外を処理する適切な方法がない場合は、通常、例外をキャッチするべきではありません。
e.printStackTrace()何も問題がないかのように実行して続行することで例外を「処理」するコードが多すぎるのを見てきました。そのような問題を無視すると、通常、後で他の問題が発生します。
于 2012-11-06T12:51:45.960 に答える
4
実行時の例外をキャッチすることを禁じるものはありません。
最近の傾向は、実行時例外をますます使用し、チェックされる例外をますます少なくすることです。Spring、Hibernate、および最新のJava EE仕様は、ランタイム例外をほぼ排他的に使用します。これにより、ビジネスコードが読みやすくなり、煩わしさが軽減されます。
ランタイム例外は、通常、エラーメッセージを表示するために、UIレイヤーでまったくキャッチされないか、コールスタックの最下部でのみキャッチされることを目的としています。これは、通常、このような例外が発生した場合に実行できるのはそれだけだからです。発生します。
于 2012-11-06T12:52:05.287 に答える
1
CheckedとExceptionの基本的な違いはUnchecked、前者を明示的に処理するか、で伝播する必要があることですが、後者でinheritance hierarchyは必要ありません。
また、CheckedExceptionから拡張しjava.lang.Exception、からUncheckedExceptions拡張しjava.lang.RuntimeExceptionます。これらは処理する必要がありません。RuntimeExceptionは、それ自体がのサブクラスであることに注意してくださいException。
与えられた、あなたがそれならそれでいいなら、上記のすべてのhandle情報unchecked exception。それは正常に動作し、コントロールは対応するcatchブロックに移動します。しかし、あなたはそれをすべきではありません。そうでなければ、あなたは本当にそれを必要とし、あなたはそれらを処理する適切な方法を持っています。
例：-であるを処理する必要
IllegalArgumentExceptionがありUnchecked Exceptionます。そして、次のようなエラーを処理するべきではありません：-
StackOverflowError。として、なぜその問題が発生したのか、そしてそれを処理するための適切な方法は何であるのかがわかりません。したがって、JVMに任せてください。から回復できないということですErrors。Unchecked Exception
詳細については、次のリンクを参照してください。
于 2012-11-06T12:50:45.853 に答える
1
チェックされた例外の選択は通常です：それthrowsについて何もできない場合はそれを追加catchし、それについて有用なことは何もできないが情報を追加できる場合は、元の例外を原因として新しい例外に変換しますcatch。そして、それが実行可能であり、コード内でそれについて何かをするのに適切な場所である場合は、それについて何かをします。
チェックされていない例外はもう少し注意が必要です。理想的な世界では、プログラミング/ロジックエラーを示し、アサーションの失敗とほとんど同じように処理され、捕捉されず、特に飲み込まれないようにする必要があります。
Java標準ライブラリまたは他のライブラリからのいくつかのチェックされていない例外は、私の意見では実際にチェックされた例外であるはずですが、そうではありません。これらは、呼び出し元が、そのような例外が通過していない場合でも、それらを通過している可能性があることを認識する必要がある場合ですcatch。チェックされた例外と同様にチェックされた例外については、基本的に同じルールです。何かをしたい場合はキャッチし、そうでない場合はバブルさせます。ライブラリを作成していて（アプリケーションの内部にある場合でも）、チェックされていない例外が実際には後でキャッチする必要がある場合は、ライブラリコードでチェックされた例外にラップされてキャッチして再スローすることをお勧めします。 。
一般に、チェックされていない例外がスローされないようにしてください。入力を確認してください。そうする必要はありません。catchそれでも例外がスローされる場合は、バグであり、キャッチしないでおく必要があります。catchそれが唯一の、または少なくとも明らかに最良の方法である場合にのみ、それら。
Javaライブラリに公平を期すために、この言語は、IDEがthrows句の欠落についてすぐに文句を言っておらず、自動的に入力することを提案していない時代に設計されたため、開発者の負担を軽減することで、チェックを外すことが正当化された可能性があります。しかし、最新のツールでは、言い訳はできません。
そして、他の回答で述べられているように、キャッチしてはいけないチェックされていない例外があります。
于 2012-11-06T13:46:22.730 に答える
-1
チェックされていない例外をキャッチする必要がありますか？
はいおよびいいえ。スローされる例外によって異なります。
チェックされていない例外は、理想的にはチェックしていないプログラミングエラーですか？
catchチェックされていない例外をキャッチするブロックを作成できますが、これも実行する必要があるかどうかによって異なります。そうすると、バグが長期間未解決のままになり、発見されるまでにサイズも変更される可能性があります。
それらはあなたのアプリケーションからただ泡立つべきですか？
それらが発生した場合は、原因を解決してみてください（可能であれば）。catch常にハードとファストのルールとしてそれらをしないでください。
于 2012-11-06T12:51:27.550 に答える