java - StackOverflowError をキャッチすることの害は何ですか?

Question

ちょっと興味があるんだけど。StackOverflowErrors のキャッチに関する回答で、誰かが次のように書いています。バグの場合にスローされる NullPointerException よりも、アプリケーションの状態を破壊する恐れがある StackOverflowErrors の特別な点は何ですか? 私が考えることができることの1つは、StackOverflowErrorは、通常は例外（または他のThrowable）がスローされることのない場所（単純なゲッターなど）で発生する可能性があるため、プログラムはおそらくこれに備えていないということです。もっと悪魔的な問題はありますか？

Answer 1

スタック オーバーフロー エラーは、メモリが使い果たされていることを意味するものではなく、それ自体に矛盾が生じるわけでもありません。

しかし、スタック オーバーフロー エラーは通常、バグです。例外をキャッチするのではなく、バグを修正する必要があります。バグを隠すために例外システムを使用しないでください。

スタックが深すぎるリスクがあることがわかっている場合でも (グラフ探索など)、スタックを爆発させるよりも、それを制御するためのより良い方法があります。

Error スーパークラスの Javadocから:

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

Answer 2

したがって、エラーはキャッチされるべきではない深刻な問題です。メソッドがエラーをスローする場合は、スーパー クラス (Throwable) もキャッチしないでください。 throws-clause を宣言する必要はありません。

エラー後のアプリケーションの動作は予測できないことがよくあります - エラーは異常な状態を示します

そのため、StackOverflowError がスローされた場合、アプリケーションは現時点でスタック プレースの最大数に達しています。ガベージ コレクターなどをより早く開始するために、アプリケーションを再確認することができます。