ジェネリックを例外に使用することは賢明ですか？

Question

私のチームは、throws Exceptionの使用を取り除く途中で、特定の例外を除いて取り外したり交換したりしています。

一般的なスローは、エンティティが見つからないためです。各エンティティクラスに対して汎用NotFoundExceptionまたは特定のSomeClassNotFoundExceptionを投げるべきですか？

特定の例外をスローする必要がある場合は、各エンティティタイプに対して特定のExceptionクラスを作成する必要がありますか？ジェネリック薬を安全に使用できますか？このclass NotFoundException<T extends EntityBaseClass> extends Exceptionのようにして、コンストラクタが処理しているエンティティタイプを宣言しますか？

ジェネリックを使用しない特定の例外をスローする必要がある場合、その例外は抽象クラスまたはインタフェースNotFoundExceptionを拡張または実装する必要がありますか？

Answer 1

質問

我々は、各エンティティタイプのための特定の例外クラスを作成するべきであるため、単純なリトマス試験？

である私たちは他のクラスによっていくつかのクラスX としないことで、投げ「が見つかりません」例外をキャッチしますcatch句を記述する必要がありますどのような状況はありますか？

回答が「はい」の場合、別のClassXNotFoundExceptionが必要です。そうでなければ、おそらくそうではありません。

質問の後半については、言語では例外タイプのジェネリックの使用が許可されていません。

Answer 2

一般的な例外を作るために許可されていません - それは（JLS §8.1.2）がコンパイルされません。

それはコンパイル時エラーと一般的なクラスはThrowableを

の直接または間接のサブクラスである場合

ジェネリック型のパラメータは実行時に消去されるため、catch句にタイプパラメータの異なる一般的な例外を区別する方法がないため、一般的な例外はサポートされません。したがって、実際には一般的な例外の使用に関する選択肢はありません。

Answer 3

エンティティタイプごとに特定のExceptionクラスを作成する必要がありますか？

コードの呼び出し元がエンティティ定義の位置を突き止めることから合理的に回復でき、エンティティタイプごとに異なるリカバリ戦略をとることができれば恩恵を受けることができます。そうでなければいいえ。

安全にgenericsを使用できますか？このクラスのように、NotFoundExceptionはExceptionを継承し、コンストラクタは処理しているエンティティの型を宣言します。

コードの発信者が障害に関連するエンティティタイプを切り替えるのに役立ちません。型消去して、それが

try { 
    callYourCode(); 
} catch (MyParameterizedException ex) { 
    // some handling code 
} catch (MyParameterizedException ex) { 
    // some different handling code for type b 
} 

と第二catchブロックするように見えるので

あなたが原因型消去に例外タイプMyParameterizedException<T>を定義した場合でも、呼び出し側は

try { 
    callYourCode(); 
} catch (MyParameterizedException<TypeA> ex) { 
    // some handling code 
} catch (MyParameterizedException<TypeB> ex) { 
    // some different handling code for type b 
} 

を行うことはできません到達不能なコードなので、コンパイル時にjavacで拒否されます。最初のキャッチブロックは、タイプbに対して入力され、エンティティ（および他のタイプも同様）を入力します。

ジェネリックを使用せずに特定の例外をスローする必要がある場合、その例外は抽象クラスまたはインタフェースNotFoundExceptionを拡張または実装する必要がありますか？

あなたのコードの発信者が、そうでなかった場合に驚くかもしれません。

あなたのコードの呼び出し元は、はい、他のNotFoundException Sを処理するコードで扱うエンティティの障害を持っていることから恩恵を受ける場合。

コードの呼び出し側が、他の条件と同じように扱われるエンティティタイプ定義の検索に失敗したくない場合は、いいえ。

Answer 4

私は皆の答えは、あなたが特定の例外を必要としないと言っていると思います。私は、Hibernateが例外を見つけられないと定義する方法を見ていました。私はEntityNotFoundExceptionを見つけました。あなた自身の例外を作成すべきではないということを追加します。これを再利用するだけです。これはRuntimeExceptionを拡張します。これは、あなたが人にそれをキャッチすることを強制していないことを意味します。しかし、そうしたいなら、J2EEの既存のクラスを再利用することができます。新しいコードを書くよりも常に優れています。代わりに使用したの

Answer 5

は：

public Class EntityNotFoundException<T extends EntityBaseClass> extends Exception { 

} 

あなたは使用する必要があります。

public Class EntityNotFoundException extends Exception { 
    private Class<? extends EntityBaseClass> clazz; 

    public EntityNotFoundException(Class<? extends EntityBaseClass> clazz) { 
     this.clazz = clazz; 
    } 

    . . . 
} 

この方法であなたは例外を生成しているエンティティタイプへの参照を保持することができます。 は EntityBaseClassを拡張しないよう顧客を検証します

throw new EntityNotFoundException(Customer.class); 

コンパイラ：あなたが使用することができ、この例外のいずれかをスローします。