19

アプリケーションのカスタムExceptionクラスを設計しています。非常に基本的な質問があります。ExceptionクラスまたはThowableクラスから拡張する必要がありますか？メリットは何ですか？

これを下にあるレイヤーからスローして、トップレベルのクラスでキャッチするつもりです。Thowable overExceptionを使用するという私の決定に影響しますか？Thowableを捕まえるのは基本的に正しいですか？

私はこのフォーラムで他のいくつかのスレッドを通過しました。彼らは、スタックトレースがスローされたときに維持され、例外などのために保持されないことについて話します。Thowableは例外のスーパークラスであり、使用すべきではないと言う人もいることを理解しています。しかし、他の人（ここ）は、例外は「例外的な」場合のためであると言います。

この質問は、方法を尋ねるのではなく、ある人が他の人よりどのように優れているかについての議論です。

4

3 に答える 3

27

Throwable発生する可能性のあるすべての悪い状況のクラスです：エラーと例外。

Error何かです、あなたはまったく扱うことができません：OutOfMemoryError、、VirtualMachineErrorなど。

Exception例外的な場合です。

例外には2つのフレーバーがあります。

  1. RuntimeExceptions。

    これらのもの、あなたは気づいていません：NullPointerException、、ClassCastExceptionなど。

  2. Checked例外。

    これらは例外であり、コードはこれを認識しており、明示的にキャッチする必要があります（... throws MyException）：IOExceptionsなど。

コードのユーザーにいくつかの例外的な状況を明示的に処理させたい場合は、を拡張するExceptionのではなく、単に拡張することをお勧めしますRuntimeException。を拡張する必要はありませんThrowable。

于 2013-02-15T09:49:32.557 に答える
4

基本的にException、作成するときにクラスを拡張する必要がありますCustom Exception。ExceptionそしてError両方とも拡張しますThrowable、それは実際に拡張する意味がありませんThrowable。

于 2013-02-15T09:40:24.207 に答える
4

ThrowableError＆のスーパークラスですException。

同様Exceptionに、Error投げて処理することもできます。

ただし、次のドキュメントによると、お勧めできません。

ErrorオブジェクトまたはErrorサブタイプをキャッチする必要はありません。自分でエラーをスローすることもできます（ただし、AssertionErrorを除いて、おそらくそうしたくないでしょう）。エラーをキャッチすることもできますが、おそらくそうはなりません。たとえば、OutOfMemoryErrorが発生した場合、実際に何をしますか？

この概念を念頭に置いて、Throwable投げたりキャッチしたりする場合は拡張することをお勧めしExceptionますError。Exception投げたりキャッチしたりするだけの場合は延長しますException。

于 2013-02-15T09:51:14.813 に答える