Est-ce toujours un contre-modèle si nous enregistrons un message d'exception et levons une exception différente?

Notre webapplication utilise un ExceptionMapperà la carte des exceptions à Response. Nous enregistrons les messages d'exception avant de lancer une nouvelle exception les suivants:

catch (SomeException ex) {
  LOG.error(ex.getMessage());
  throw new MyException(ex.getMessage());
}

Nous ne repoussons pas la même exception , donc ma question est de savoir si cela serait considéré comme un contre -modèle Log and Throw . Et ainsi, serait - il préférable d'enlever l'exploitation forestière dans des endroits semblables et les déplacer à plusieurs ExceptionMapperclasses:

@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();
  }
}

java anti-patterns

— Diyarbakir
source

Je vous arrêterais dès que vous vous connecteriez ex.getMessage(), c'est déjà faux.

— biziclop

doublon possible Pourquoi devriez - vous signaler le texte du message d'exception?

Défendables, reprenant le texte du message d'exception est toujours une mauvaise idée .

OMI, il n'est pas vraiment juste de ne pas mentionner du tout qu'il s'agit d'un service Web. Cela change vraiment les règles du jeu, car par exemple, le simple fait d'utiliser des mécanismes de gestion des exceptions ordinaires peut constituer un risque pour la sécurité; vous ne voulez pas que toute exception soit renvoyée dans une réponse d'erreur 500, qui doit être vérifiée et filtrée. La journalisation agressive sur place est également beaucoup plus courante lorsque vous traitez avec des systèmes qui ont des clients externes qui l'invoquent directement. La journalisation des traces de pile dans les appels de service qui sont invoquées à plusieurs reprises peut entraîner des tailles de fichier journal ingérables et des problèmes de performances.

@Gimby Dans ce cas , OP ne transmet aucun détail d'erreur dans la réponse (peut - être un boilerplate « erreur » contenu). De plus, comment diagnostiquez-vous un problème sans trace de pile? Les enregistreurs à rouleaux prennent régulièrement en charge la taille du stockage et les données des journaux sont compressibles de manière embarrassante.

— Marko Topolnik

Votre code ne comporte en fait pas un, mais trois contre- modèles:

se connecter et retomber;
renvoyer sans envelopper la cause d'origine;
consigner uniquement le message et non la trace de pile (c'est le pire).

Si vous avez suivi la meilleure pratique pour:

ne pas attraper du tout (laissez l'exception se propager d'elle-même);
s'il est forcé d'attraper une exception vérifiée, encapsulez-la sans contrôle et relancez;
ne connectez jamais rien sauf au niveau supérieur;
consigner l'intégralité de la trace des exceptions avec log.error("Error occurred", e);

vous ne rencontriez alors aucun dilemme, y compris le vôtre, car la trace de pile consignée inclurait également toutes les exceptions encapsulées.

— Marko Topolnik
source