Ist es immer noch ein Antipattern, wenn wir eine Ausnahmemeldung protokollieren und eine andere Ausnahme auslösen?

Unsere Webanwendung verwendet eine ExceptionMapper, um einige Ausnahmen zuzuordnen Response. Wir protokollieren die Ausnahmemeldungen, bevor wir eine neue Ausnahme auslösen:

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

Wir lösen nicht dieselbe Ausnahme erneut aus , daher ist meine Frage, ob dies als ein Protokoll- und Wurf-Antipattern angesehen wird . Daher ist es besser, die Protokollierung an ähnlichen Stellen zu entfernen und sie ExceptionMapperwie folgt in die verschiedenen Klassen zu verschieben :

@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
quelle

Ich würde dich stoppen, sobald du dich eingeloggt hast ex.getMessage(), das ist schon falsch.

— biziclop

mögliches Duplikat von Soll der Meldungstext von Ausnahmen gemeldet werden?

Es ist immer eine schlechte Idee , den Meldungstext von Ausnahmen zu melden .

IMO ist es nicht wirklich fair zu erwähnen, dass dies ein Webservice ist. Das ändert die Spielregeln wirklich, da zum Beispiel die Verwendung regulärer Mechanismen zur Ausnahmebehandlung ein Sicherheitsrisiko darstellen kann. Sie möchten nicht, dass alle Ausnahmen nur in einer 500-Fehler-Antwort zurückgesendet werden, die überprüft und gefiltert werden muss. Aggressive Protokollierung vor Ort ist auch weitaus häufiger, wenn es sich um Systeme handelt, auf die externe Clients direkt zugreifen. Das Protokollieren von Stacktraces in Dienstaufrufen, die wiederholt aufgerufen werden, kann zu nicht verwaltbaren Protokolldateigrößen und Leistungsproblemen führen.

@Gimby In diesem Fall sendet OP in der Antwort keine Fehlerdetails (wahrscheinlich ein Inhalt, bei dem ein Kesselschildfehler aufgetreten ist). Wie diagnostizieren Sie ein Problem ohne Stacktrace? Rollende Logger kümmern sich routinemäßig um die Speichergröße und Logdaten sind peinlich komprimierbar.

— Marko Topolnik

Ihr Code enthält nicht nur ein, sondern drei Antimuster:

loggen und neu werfen;
erneut werfen, ohne die ursprüngliche Ursache einzuwickeln;
protokolliere nur die Nachricht und nicht den Stacktrace (dies ist der schlechteste).

Wenn Sie die Best Practice befolgt haben, um:

überhaupt nicht fangen (die Ausnahme soll sich von selbst ausbreiten);
Wenn Sie gezwungen sind, eine aktivierte Ausnahme abzufangen, wickeln Sie sich in eine nicht aktivierte Ausnahme und werfen Sie sie erneut.
protokolliere niemals etwas anderes als auf der obersten Ebene;
protokolliere das gesamte Exception Stacktrace mit log.error("Error occurred", e);

Dann stünden Sie nicht vor einem Dilemma, einschließlich Ihres aktuellen, da der protokollierte Stacktrace auch alle umschlossenen Ausnahmen enthielte.

— Marko Topolnik
quelle