3

アプリケーションのパフォーマンスに悪影響を与えることは知っていますが、コードの場所を囲むべきではありません。

try {
    // code        
} catch (OutOfMemoryError ex) {
    // handling code
}

かなり安全そうです。

ドキュメントから：

Error は、Throwable のサブクラスであり、合理的なアプリケーションがキャッチしようとすべきではない重大な問題を示します。

なぜだめですか？

4

5 に答える 5

11

通常、これらのエラーを処理しようとすべきではない理由は、多くの場合、エラーに対してできることは何もないからです。

これらは、アプリケーション レベルのエラーではなく、JVM レベルのエラーである傾向があります。ここでは、OutOfMemory が良い例です。JVM がメモリ不足になった場合、プログラムはどうしますか? そして、それをキャッチしたとしても、スローされた終了条件を考えると、処理コードが一貫した方法で完了/続行するという保証はありません

于 2013-03-06T08:26:13.593 に答える
2

エラーをキャッチできることを意味する、スロー可能なものは何でもキャッチできます。しかし、エラーは重大な問題を表しており、キャッチすることはお勧めできません。

Java API から:

「エラーは、合理的なアプリケーションがキャッチしようとすべきではない重大な問題を示す Throwable のサブクラスです。そのようなエラーのほとんどは異常な状態です。「通常の」状態ですが、ThreadDeath エラーも Error のサブクラスです。 >アプリケーションはそれをキャッチしようとすべきではありません。」

エラーは、アプリケーションの重大な問題を表しています。たとえば、OutOfMemoryErrorは、メモリ不足のために がオブジェクトを割り当てるJava Virtual Machineことができず、ガベージ コレクタによって使用できるメモリがなくなった場合にスローされます。したがって、キャッチしても実際の問題が解決されない場合は、プログラムでこのエラーをキャッチしても解決策が得られず、エラーが発生しやすいアプリケーションが発生する可能性があります。したがって、エラーをキャッチすることはお勧めできません。OutOfMemoryError increasing the memory

于 2013-03-06T08:27:10.183 に答える
1

JVM が期待どおりに動作しなくなった場合、または動作する寸前である場合、エラーが発生します。エラーをキャッチした場合、catch ブロックが実行される保証はなく、最後まで実行される保証はさらにありません。

また、実行中のコンピューター、現在のメモリの状態にも依存するため、テストして最善を尽くす方法はありません。危険な結果しか得られません。

コードの可読性も低下します。

于 2013-03-06T08:30:40.007 に答える
1

Error実際にこれを推測できないタイプは、次のperticular block of Codeようになります。

try {
    // not guaranty OutOf memeroy Exception will come from this block      
} catch (OutOfMemoryError ex) {
    // handling code
}

そのため、お取扱いいたしません。

于 2013-03-06T08:25:09.107 に答える
0

ヒープ スペースまたは perm gen スペースがいっぱいの場合に、OutOfMemoryError をキャッチし、catch ブロックで何らかの作業を行う意味は何ですか? 実際には、この例外が実際にどこで発生するかを推測することはできません。この例外をキャッチするロジックはありません。

于 2013-03-06T08:26:55.957 に答える