4

それで、これは私が最近尋ねられたインタビューの質問に関するものです. インタビュアーは、カスタム例外をどのように作成するかを私に尋ねることから始めました。それに答えると、彼は私に RunTimeExceptions を作成する方法を尋ねました。チェック済み例外を作成するのと同じ方法でそれらを作成すると言いました。カスタム例外だけが RunTimeException クラスから拡張されます。次に、どのシナリオで独自の RunTimeException を作成するかを尋ねました。今、私はそれに対する良い答えを思いつきませんでした。私のプロジェクトでは、カスタムの RunTimeExceptions を作成しませんでした。

また、RunTimeExceptions を作成するべきではないと思います。JVM は限られた数の方法でのみ失敗する可能性があり、それらを適切に処理します。アプリケーションを作成している間は、どのランタイム例外が発生するか予測できないため、それらを処理する必要はありません。これらの条件を予測できれば、それらは RunTimeExceptions ではありません。新しい実行時例外も実行時例外の処理も必要ないので、なぜカスタムの RunTimeException を作成する必要があるのでしょうか。起こりうる障害条件として事前に考えられるものはすべて、コンパイル時に処理する必要があり、それはチェック例外になります。右？コンパイル時に処理できないものと、実行時に依存するものだけが RunTimeExceptions のカテゴリに入ります。

カスタム RunTimeExceptions を作成し、その RunTimeException をスローするカスタム メソッドを記述したとしても、メソッドがその特定の RunTimeException をスローすることを確認するにはどうすればよいでしょうか。そのマッピングをどのように行うか。私には不可能に思えます。

ここに何か/多くのものが欠けていますか? 親切にアドバイス。

ありがとう、チャン。

4

4 に答える 4

6

インタビュアーは、ランタイム例外の目的を理解しているかどうかを確認しようとしていたと思います。これは、プログラマーのエラーを通知することです (実行環境の問題を通知するアプリケーション例外とは対照的です)。

RuntimeExceptionメソッドがプログラミング エラーに相当する条件を通知する必要があり、例外が説明するエラーに関する追加情報を提供する必要がある場合はいつでも、サブクラスを作成できますし、作成する必要があります。

たとえば、スパースな多次元配列にデータを格納できるクラスを考えてみましょう。そのようなクラスがおそらく提供する API の 1 つは、インデックスの配列を取る getter です。インデックスの数は配列の次元数と同じである必要があり、各インデックスはその範囲内にある必要があります。間違った数の要素を持つ配列パラメーター、またはその境界外に 1 つ以上の要素を持つ配列パラメーターを指定すると、プログラミング エラーになります。実行時例外で通知する必要があります。このエラーを通知し、何が問題なのかを完全に説明したい場合は、 のサブクラスIllegalArgumentExceptionであるサブクラス がRuntimeException独自の例外を作成します。

最後に、 をサブクラス化したい場合のもう 1 つの状況があります。「通常の」例外を提供する必要があるが、ユーザーが API の各呼び出しを/ブロックRuntimeExceptionでラップすることを望まない場合です。このような状況では、単一のメソッドを置き換えることができますtrycatch

void performOperation() throws CustomApplicationException;

メソッドのペアで

boolean canPerformOperation();
void performOperation();

最初のメソッドは、現在の状態で 2 番目のメソッドを呼び出しても安全であることを呼び出し元に伝えます。例外をスローすることはありません。

2 番目のメソッドは、最初のメソッドが を返す状態でのみ失敗falseし、失敗をプログラミング エラーにするため、RuntimeExceptionそのような失敗を通知するために を使用することが正当化されます。

于 2013-07-31T09:53:05.493 に答える
1

RuntimeException次の場合は、独自のサブクラスを作成します。

  • 呼び出し元が例外を明示的にキャッチすることを期待していないため、それをチェック例外にしたくありません。(個人的には、チェック済み例外は標準ライブラリでかなり使いすぎていると思います。)
  • メッセージだけでなく、より多くの情報を提供したい場合もあります (ログの開始点として、タイプ自体が役立ちます)。

HibernateExceptionHibernate ORM での例です。

于 2013-07-31T09:50:07.973 に答える
0

Custom Exceptions を作成しているときは、サブクラス化しないでくださいRuntimeException。カスタム例外を作成する目的全体が無効になります。

カスタム RunTimeExceptions を作成し、その RunTimeException をスローするカスタム メソッドを記述したとしても、メソッドがその特定の RunTimeException をスローするようにするにはどうすればよいでしょうか。

ここでのポイントは、実際にはメソッドの呼び出し元がtry-catchチェック例外ではないため、ブロックでそれを囲む必要がないということです。ロギングなどに追加のカスタム情報を提供するためだけに、カスタムの未チェックの例外をスローする正当な理由がない限り、そうしないでください。別の悪い実装は、コード内のチェック済み例外をキャッチし、カスタムの未チェック例外をスローして、呼び出し元コード内のすべての try-catch を取り除くことです。

于 2013-07-31T09:48:45.270 に答える