java.lang.Error捕まえるべきではないと言っている投稿がたくさんあります。私の質問は、それが何の使用法であるかを理解するべきではないかどうかです。スローアブルなので、トライキャッチでキャッチできます。私はそれが捕らえられるべきであるいくつかの状況でのみ、これらの状況を知る方法のようないくつかの投稿を読みました。
要するに、エラーをキャッチしたときに何がうまくいかないのか知りたいのです。その背後にあるプロセスは何ですか。なぜ彼らはエラーとそのサブクラスを作ったのですか？私のアプリがそれらをキャッチすることになっていない場合、何がそれらをキャッチしますか？なぜ私のコードはこのキャッチされたエラーを処理できないのですか？単に1つのエラーをキャッチし、Catchブロックに処理コードを記述した場合、そのコードは実行されませんか？
エラー (特に VirtualMachineError のサブクラス) は、JVM で内部の問題が発生したことを示します。これは、その内部状態が一貫していない可能性があることを意味します。エラーをキャッチして回復を試みた場合、将来の動作は未定義です。エラーがスロー可能である理由は、エラーをスローできるようにするためです。たとえば、回復できないネイティブ ライブラリのエラーに対して自分で行うことができます (たとえば、ライブラリが JVM メモリに書き込まれたか、内部の静的状態が破損している可能性があります)。 ）。すべての Throwable の場合、同じスタック ウォーキングとスタック トレース生成機構が使用されます。同じことを行う別のメカニズムを用意するのはばかげています。
VirtualMachineErrors ではない JVM のほとんどのエラーは、ネイティブ ライブラリがその静的状態を破壊した可能性がある状況です (AWTError、ZipError など)。
ただし、まれに、エラーをキャッチしても問題ない場合があります。テスト フレームワークの AssertionError や、実行時に異なるバージョンのライブラリの有無に対処する必要がある LinkageError です。これは非常にまれな要件であり、リフレクションによってより適切に処理される場合があります。
すべてのルールには例外があります (これを除く)。
誰もがすべきではないと言っているとしても、これらの java.lang.Error をキャッチすることが完全に適切な場合はたくさんあります。ルールの背後にあるロジックは、「致命的な状態が検出された後、アプリケーションの実行を継続しようとしない」というものでした。したがって、このようなエラーがスローされた後に何かを行う前に注意する必要があります。その後、システムがタスクを続行できなくなる可能性があります。
サーブレットが OutOfMemoryError をキャッチし、エラーをログに記録し、セッションを破棄しても問題ない場合があります。おそらく、問題はその正確なセッションにあったのでしょう。それを破棄すると、メモリが復元され、他のユーザーがシステムを引き続き使用できるようになります。ただし、次のことを行うために、これらのエラーをリアルタイムで追跡するメカニズムが必要です。
この種の処理は、メイン ループ (または同等のループ) が実行されるコール スタック (つまり、main() の近く) の非常に「高い位置」で実行する必要があります。深いコードでエラーをキャッチするのは良い習慣ではないと思います。そのような場合、少なくともエラーを再スローする必要があります。
同様の質問はすでにここで回答されています-java.lang.Errorをキャッチするタイミングは？
基本的に、スレッドが何らかの理由で停止し、回復できない場合など、かなり深刻な問題でスローされるため、キャッチしようとしないでください。ただし、上記のURLに記載されているように、フレームワーク自体を処理するときにエラーをキャッチする必要がある場合があります。