エラーをキャッチした後に JVM の状態がわからない可能性があるため、エラーをキャッチするOutOfMemoryErrorことが非常に推奨されない場合、エラーをスローする代わりに、JVM を単純に終了して何らかの方法でユーザーに通知しないのはなぜですか?
5 に答える
5
エラー状態をユーザーに報告する単一の標準的な方法がないためです。エラーをスローすると、オブジェクトをトップ レベルでキャッチし、終了前に適切な状態 (コンソール メッセージ、ログ ファイルへの書き込み、ダイアログの表示など) のレポートを作成できます。ドキュメントには、合理的なアプリケーションはエラーをキャッチすべきではないと記載されていますが、これは事実です。エラーを処理する最良の方法は、フレームワーク コードで処理することです。これは、エラーの処理方法にはほとんど (ゼロではありませんが) バリエーションがあるためです。具体的には、それらをから現実的に復元することはできません。そのため、ほとんどのアプリケーション作成者はそれらを見つけようとします。
更新: 別の理由もあります。エラーをスローすると、エラーがキャッチされるだけでなく、「finally」ブロック内のコードが実行されます。これらのブロックには重要なクリーンアップ コードが含まれている可能性があるため、アプリケーションが終了する前に実行できるようにすることが重要です。
于 2013-08-30T20:21:23.513 に答える
1
アプリケーションが終了していない場合は、データをダンプしたり、他の方法で OOME の理由を特定したりすることができます。
キャッチされない場合は、エラーが開始されたスレッドを終了します。もちろん、OutOfMemoryErrors も引き起こさない限り、他のスレッドは正常に実行され続けます。
JVM が一貫性のない状態にある可能性があるため、何があっても JVM を強制終了したい場合は、これを Java オプションに追加します。
-XX:OnOutOfMemoryError="kill -9 %p"
于 2013-08-30T20:05:09.363 に答える