これは奇妙な質問かもしれませんが、try-catchブロックは特定のコードブロックを実行するだけでなく、サーバー環境のメモリにそれ以上のものを追加します。たとえば、プリントスタックトレースを行う場合、JVMは詳細情報を保持していますか？または、ヒープ上に保持される情報が増えていますか？例外処理とメモリ
try {
... do something()
} catch(Exception e) {
e.printStackTrace();
}
... do something()
例外はスタックトレースへの参照です。 printStackTraceはスタックトレースを何かにかなりフォーマットするので、より多くのメモリを割り当てます。
のtry catchブロックは、おそらく例外変数「E」が到達可能なもはや（すなわち、アウトです
例外が作成されるとスタックトレースが構築されます。スタックトレースを印刷しても、何か他のものを印刷するよりもメモリに多大な負荷はかかりません。
try/catchブロックにはパフォーマンス上のオーバーヘッドがありますが、メモリ要件が増えることはありません。
ここで重要なのは、すぐにあるメモリ割り当て大部分は静的コード/データセグメントではなく、実行時に発生しませんスコープの範囲）、それはメモリ収集に適格になります。
ほとんどの場合、例外が発生した場合のメモリ/パフォーマンスについて心配しないでください。一般的なコードパスである例外がある場合は、例外を誤って使用している可能性があります。
あなたの質問が学術目的のためのものであれば、私はヒープ/メモリ空間に関して何が起こっているのか分かりません。しかし、Joshua Blochの "Effective Java"では、try catchブロックのcatchブロックは、ほとんどのJVM実装では比較的しばしば最適化されていないことが記述されています。
技術的には、あなたの質問に対する答えはおそらくいいえです。可能な限り例外をスローするのを避ける理由はたくさんありますが、メモリは本当に懸念されていません。
本当に例外的な条件の例外をスローする本当の理由は、それが遅いということだけです。例外を生成するには、スタックを慎重に調べる必要があります。速い操作ではありません。定期的な実行フローの一環として実行している場合は、速度に著しい影響を与えます。私は、あるクラスがExceptionを生成し、その方法でスタックを調べることで、どのクラスがそれを呼び出したかを自動的に認識したので、私はかつて非常に賢いと思ったログシステムを書きました。やがて私は戻って、その部分を取り除かなければならなかった。
メモリ消費には直接関係しませんが、ここではスレッドがありましたが、後で議論しますHow slow are the Java exceptions?私の意見では、一見価値があります。
私もこのブックマークに含められましたlink。私が思い出す限り、例外スロー時にスタックトレースの生成をスキップすると速度アップの例が得られましたが、現時点ではサイトがダウンしているようです。