300個の例外に対して300個のエラーを作成するような過剰使用のようです。私がやったことは私たちが返すことにしたいHTTPエラーを含む私たち自身のHttpErrorException
クラスを作成することでした。開発者は、例外またはエラーが発生したときに、そのうちの1つをスローするように指示されました。新しいHttpErrorExceptions
の1つではない例外が発生した場合は、500が返されます。特定のExceptionが常に特定のHTTPエラーにマップされると仮定するのは間違っていると感じたので、他の例外をHTTPエラーに変換しませんでした。なぜなら、多くの依存関係(私たちが使用している他のライブラリ)があり、特定の状況では私たちが気にしていたHTTPエラーにうまく対応しないかもしれないあらゆるタイプの例外が投げられるからです。だから私はむしろ明白である。
典型的な使い方の例です。
Account getAccount(String id){
Account a = null;
try{
a = accountRepo.findById(id);
catch(Exception e) {
String error = "Got exception while trying to get Account from db.";
logger.(error, e);
throw new HttpErrorException(500, error);
//or throw new HttpErrorException(HttpStatus.INTERNAL_SERVER_ERROR, error);
}
throw404IfNull(a);
return a;
}
throwIf404IfNull
は、我々のコードでif
ステートメントを減らすために作成しただけの簡単な方法です。これらのメソッドのいくつかがあり、コードにはif
のステートメントが含まれていません。
void throw404IfNull(Object obj){
if(obj == null) {
throw new HttpErrorException(400, "Object was not found");
}
}
は、我々は例外であるエラー状態と素敵うまくフォーマットされたHTTPエラーが発生したため、すべてHttpErrorException
年代をマッピングするためにSpringの例外処理機能を使用します。
1. **いいえ**。 2.開発者が回復するのに合理的な方法でエラーを分類する。スタックトレースは例外がどこで発生したかを示します。そのため、カスタムカスタム例外を300個作成する理由が明確ではありません。 –
本当に多くのカスタム例外を作成する必要はありません。おそらく、既存の例外クラスは、作成した多くの例外ではなく、十分に使用できることがわかります。次に、例外ごとに異なるメッセージと原因をコンストラクタに渡すことで、これらをより具体的にすることができます。 https://www.cs.cmu.edu/~pattis/15-1XX/15-200/lectures/exceptions/lecture.html https://docs.oracle.com/javase/7/docs/api/java/ lang/Exception.html –