私たちのウェブアプリケーションはを使用しExceptionMapperていくつかの例外をにマップしていますResponse。次のように、新しい例外をスローする前に例外メッセージを記録します。
catch (SomeException ex) {
LOG.error(ex.getMessage());
throw new MyException(ex.getMessage());
}
私たちは同じ例外を再スローしていないので、私の質問は、これがLog and Throwアンチパターンと見なされるかどうかです。したがって、同様の場所でロギングを削除し、ExceptionMapper次のようにいくつかのクラスに移動する方が良いでしょう：
@Provider
public class MyExceptionMapper implements ExceptionMapper<MyException> {
// bla bla
@Override
public Response toResponse(final MyException ex) {
LOG.error(ex.getMessage());
return Response.status(400).entity("something").build();
}
}
可能性のある重複べきで、あなたは、例外のメッセージテキストを報告しますか？
間違いなく、例外のメッセージテキストを報告することは常に悪い考えです。
IMOこれがウェブサービスであるとまったく言及しないのは本当に公平ではありません。たとえば、通常の例外処理メカニズムを使用するだけではセキュリティリスクになる可能性があるため、これはゲームのルールを実際に変更します。すべての例外を500エラー応答で返送するだけでは望ましくないので、チェックしてフィルタリングする必要があります。積極的なオンザロギングも、外部クライアントが直接それを呼び出しているシステムを扱う場合、はるかに一般的です。繰り返し呼び出されるサービス呼び出しでスタックトレースを記録すると、管理できないログファイルサイズとパフォーマンスの問題が発生する可能性があります。
@Gimbyこの場合、OPは応答でエラーの詳細を送信しません（おそらく「エラーが発生した」定型的なコンテンツ）。また、スタックトレースなしで問題をどのように診断しますか？ローリングロガーは定期的にストレージサイズを処理し、ログデータは非常に圧縮されます。
—
マルコトポリニク
ex.getMessage()、それはすでに間違っています。