たまに
try {
} catch(Throwable e) {
}そして時折
try {
} catch(Exception e) {
}違いはなんですか？
回答:
キャッチするThrowableことにより、サブクラス化するものが含まれErrorます。おそらく、ログに記録したいスレッドの最も高い「すべてをキャッチ」レベルで実行するか、そうでなければ、問題が発生する可能性のあるすべてを完全に処理する場合を除いて、通常はこれを行わないでください。フレームワークタイプのアプリケーション（アプリケーションサーバーやテストフレームワークなど）では、不明なコードが実行されている可能性があり、そのコードで問題が発生することによる影響をできるだけ受けないほうが一般的です。
throw new Throwable();ことを妨げるものは何もないので、それがすべてを本当にキャッチする唯一の方法です。
最初のものはThrowable（これを含むExceptionおよびError）のすべてのサブクラスをキャッチし、2番目はのすべてのサブクラスをキャッチしますException。
Errorロギングの目的（それが再び通過する）を除いて、プログラムで何らかの方法で回復できず、通常は捕捉されません。Exceptionプログラムで回復可能です。そのサブクラスRuntimeExceptionはプログラミングエラーを示し、通常は捕捉されません。
Error、2）ログがない場合、OOMが発生したことを通知されない可能性があり、サーバーがなぜ「おかしい」動作を開始したのか疑問に思う
programmatically unrecoverable正確にはどういう意味ですか？それが非常に厳しいので、JVMから予期しない動作が発生する可能性がない限り、それをキャッチした後（ロギングなど）に基本的にJavaメソッドを呼び出すことはできませんか？
Its subclass RuntimeException indicates a programming error：私がこの声明に同意するかどうかはわかりません。それが真の場合、それはすべての予期される例外がチェック例外であるべきであることを意味します。何かが失敗する可能性があり、自分のアプリケーションで回復できないと予想しても、少なくとも意味のある例外をスローしたい場合はどうなりますか？その場合、チェック済み例外を使用しても役に立たないようで、定型コードが作成されます。
ThowableデフォルトでスローされるThreadDeathでさえ、実際にはすべてをキャッチして、現在非推奨のThread.stop()メソッドからスレッドを停止します。したがって、キャッチThrowableすることで、少なくともキャッチブロックを通過せずにtryブロックを離れることはありませんが、処理OutOfMemoryErrorおよびInternalError/またはStackOverflowError。
キャッチThrowableは、あらゆる種類の要求を外部コードに委任するが、サービス自体を維持するためにそれ自体が終了することはない外部サーバーループに最も役立ちます。
ThrowableExceptionだけでなくのスーパークラスですError。通常の場合、常にサブクラスをキャッチする必要がありますException、根本的な原因が失われないよう、があります。
Javaコードを制御できない問題が発生する可能性がある特殊な場合のみ、Errorまたはをキャッチする必要がありThrowableます。
ネイティブライブラリが読み込まれていないことを示すためにThrowableをキャッチしたことを覚えています。