2016-04-07 11 views
0

Derzeit meine Anmeldungen wie folgt aussehen:Handelt es sich um alle möglichen (nicht aktivierten) Ausnahmen?

public void signup(User newUser) throws Exception { 
    log.info("Sign up: " + newUser.getEmail()); 
    if (restService.emailAlreadyExists(newUser.getEmail())) { 
     throw new Exception("Email already in use."); 
    } 
    List<Role> roles = new ArrayList<Role>(); 
    roles = roleRepository.findAllOrderedByName(); 
    roles.add(roleRepository.findByName("user")); 
    newUser.setRoles(roles); 
    newUser.setPassword(restService.getHashedValue(newUser.getPassword())); 
    try { 
     em.persist(newUser); 
    } catch (Exception e) { 
     throw new Exception("Just noobs use apps with less bugs. Try again. Now!"); 
    } 
    log.info(newUser.toString()); 
    userEvent.fire(newUser); 
} 

In erster Ordnung ich in zwei Nachrichten nur daran interessiert bin (wird FacesMessage werden) für den Benutzer. Um andere kryptische Nachrichten für den Benutzer zu verhindern, müsste ich sogar den try-Block auf Rollen erweitern.

Nun, das wäre schlechte Praxis, denke ich. Auch mit einem generischen Exception riecht es, sagen sie. Aber: ich erkennen, in diesem kleinen Stück Code Exception s dokumentiert folgende:

  • IllegalStateException
  • IllegalArgumentException
  • EntityExistsException
  • TransactionRequiredException
  • ObserverException

Auch nicht über die acht sprechen (!) Exception s der Methode getSingleResult() von javax.persistence.TypedQuery.

Sollte ich wirklich alle Exception s in diesem Beispiel behandeln, oder ist es in Ordnung, ein paar zu überspringen (und/oder vielleicht sogar eine generische Exception wie oben).

+2

Was Sie sich fragen sollten, ist: sollten Sie sie alle behandeln, und wie? Viele UncheckedExceptions stellen einen Fehler dar, von dem das System nicht wiederherstellen kann. Also, wie gehst du damit um, ohne die Benutzeroberfläche zu blockieren und den Benutzer zu nerven? Eine Reihe von ihnen kann behandelt werden, aber wenn es nichts gibt, was der Benutzer oder das System tun kann, um das Problem zu beheben, sollten Sie? – Stultuske

+0

Auch: Sagen wir, Sie schreiben das Backend. Weißt du, wie die Benutzeroberfläche auf eine Ausnahme reagieren soll? Von Zeit zu Zeit ist die Verbreitung der Ausnahme besser als die Annahme, dass Sie wissen, was zu tun ist. – Stultuske

+0

Siehe http://stackoverflow.com/questions/2416316/why-is-the-catchexception-almost-always-a-bad-idea – Raedwald

Antwort

0

Best Practice ist: alle Ausnahmen getrennt abfangen und so viele benutzerdefinierte Protokollmeldungen wie möglich erstellen. Es ist einfacher fehlerhafte Situationen zu verstehen und entsprechend zu handeln.

Reality in einer typischen Geschäftsanwendung ist: versuchen Sie, Ihre Ausnahmen zu gruppieren (ex. Gruppe alle möglichen Ausnahmen durch Ihre Methode verursacht, alle die durch die db usw. etc. geworfen) und lernen, dass Sie manchmal die berüchtigt catch (Exception e) oder eine generische Ausnahme mit einer generischen Nachricht wiederholen ... oder die Leute werden anfangen, dich über Protokolle anzurufen, die wie Elefanten wachsen.

+3

Ich dachte, beste Praxis wäre, so wenige Ausnahmen wie möglich zu werfen.Fangen alle möglichen Ausnahmen ist eine fruchtlose Aufgabe IMHO – Bohemian

+0

In meinem Fall wäre das keine Ausnahme (alle deaktiviert, neben den beiden, die ich sowieso wegen der Nachricht werfen möchte). Und dann wäre es auch egal, dass es eine generische Ausnahme ist, oder? – Martin

Verwandte Themen