Exceptions als Fehlerbehandlung "missbrauchen"?

[Verjigorm]

Hallo,

wollte mal fragen wie ihr das handhabt:
Ich habe nen Codeblock welcher aus zahlreichen if/else besteht, die Werte prüfen und bei falschen Eingaben entsprechend eine Fehlermeldung ausgeben sollen.

Nun hatte ich in jedem else sowas stehen:

JOptionPane.showMessageDialog(...);
return;

hab aus dem else-zweig nun sowas gemacht:

throw new Exception("fehlermeldung xy");

und im catch-block dann:

JOptionPane.showMessageDialog(frame, e.getMessage());
return;

Macht für mich das Ganze etwas einfacher zu überschauen, bringt mir noch diverse andere Vorteile und finds auch generell sauberer.

Nun halt die Frage: Ist das legitim, try/catch derart zu "missbrauchen"?
Eigentlich sollten damit ja "schwerwiegenderer" Fehler behandelt werden.
Verwirrt sowas eventuell andere, die irgendwann mal mit dem Code arbeiten müssen?

mfg Verjigorm

 

[Der Müde Joe]

Nun halt die Frage: Ist das legitim, try/catch derart zu "missbrauchen"?

Nein....es ist überaus schlecht. Klar ist es Möglich, aber es sollte nicht benutzt werden, wenn
es keinen "wirkliche" Exception ist.

 

[maki]

Exceptions zur Fehlerbehandlung sind eigentlich der vorgesehene Weg, mittlerweile gibt es aber auch Strömungen wieder mit Rückgabewerten zu arbeiten, da Exceptrionhandling schnell verwirrend werden kann.

 

[kleiner_held]

Das ist in meinen Augen kein Missbrauch sondern ganz legitim.
Es ist aber besser nicht einfach die Klasse Exception zu werfen sondern eine eigene Klasse

ValidationException extends Exception

zu verwenden.

 

[Verjigorm]

Klasse, 3 Antworten:
1 Ja
1 Nein
und 1 "zwischendrin"



edit: das mit der eigenen Exception find ich irgendwie stylisch!

 

[Der Müde Joe]

Darum Nein:

Item 39: Use exceptions only for exceptional conditions. That is, do not use exceptions for control flow, such as catching NoSuchElementException when calling Iterator.next() instead of first checking Iterator.hasNext().

von
http://www.ibm.com/developerworks/java/library/j-jtp05254.html

könnte noch ein paar Gründe aufzählen aus J.Blochs: Effective Java 2nd Ed. aber habs nicht hier

 

[maki]

Weiss nicht ob das hier passt Müder Joe, Bloch meint wenn man prüfen kann, ob eine Vorbedingung existiert, sollte man das auch mahcen (beim Iterator war das hasNext()) anstatt einfach mal einen try/catch Block drunherum zu machen.

 

[Der Müde Joe]

Dachte dabei an den Controlfluss in der Methode:

doStuff() {
try{
if() {
//bla
} else if() {
throw new Exception();
} else {
//bla
} 
} catch(E.....) {}

in der Methode eine Exception schmeissen, dass man sie evtl fangen kann.
Tönt in meinen Ohren irgenwie böse.

 

[kleiner_held]

Also erstmal, das direkte Rueckmelden der Fehler per JOptionPane waere mMn nach MVC Konzeption nicht gut, da ich annehme das das eine Model Klasse ist.

Bleibt also nur die Rueckmeldung von Validierungsfehlern.

Das geht halt entweder ueber eine spezielle checked Exception oder ueber einen return value. Return value hat den Vorteil, dass man auch mehrere Fehler sammeln kann.

public List<String> validate()

Ist die Liste leer dann ist alles i.O. ansonten hat man halt die Fehler.

Exception hat den Vorteil, dass man auch da sicherheitshalber noch einmal validieren kann, wo man den return value eigentlich anderweitig benoetigt, also ein Fall in dem ein Validierungsfehler eine echte Ausnahme ist:

public double calculate() throws ValidationException

Man kann natuerlich auch beide Konzepte mischen:

public List<String> validate() {
   [...]
}
public double calculate() throws ValidationException {
   List<String> validationResult = validate();
   if (!validationResult.isEmpty()) {
       throw new ValidationException(validationResult );
   }
   [...]
}

 

[slawaweis]

Nun halt die Frage: Ist das legitim, try/catch derart zu "missbrauchen"?
Eigentlich sollten damit ja "schwerwiegenderer" Fehler behandelt werden.
Verwirrt sowas eventuell andere, die irgendwann mal mit dem Code arbeiten müssen?

alles was geht und man selber oder im Team versteht, kann man verwenden. Es gibt keine in Stein gemeißelten Regeln die besagen, dass man so eine Situation nicht so lösen darf. Manchmal ist es auch sinnvoll mit Exceptions zu arbeiten, denn diese können von Überwachungsprogrammen, wir z.B. Profilern, erfasst und anderweitig ausgewertet werden. Doch ich würde nicht dazu raten diese übermäßig einzusetzen, ich persönlich bin kein Freund der Exceptions. Diese sollten vor allem wirklich Ausnahmen darstellen, die nicht regelmäßig auftreten, wie z.B. nicht genug Speicher, fehlende Rechte seitens des OS, Netzwerkverbindungsabbruch weil jemand das Kabel gezogen hat. Weiterhin können schlecht oder "missbräuchlich" eingesetzte Exceptions schnell zu anderen Fehlern führen. Zum Beispiel wird diese Zeile:

throw new Exception("fehlermeldung xy");

und das Abfangen dieser Exception alle anderen möglichen Exceptions überlagern. D.h. man geht davon aus, in diesem Block treten nur die eigenen Fehler auf, aber wenn jetzt eine Division durch 0 kommt oder ein ArrayIndexOutOfBoundsException, dann hat man plötzlich ein Problem, dass zu unterscheiden. Eine eigene Klasse für die Exception wäre also Pflicht. Doch auch dann tritt das Problem auf, dass man andere Exceptions, die vielleicht in höheren Schichten behandelt werden, in diesem Block kapselt und entweder ganz unterdrückt oder mühsam nach Oben durchschleifen muss.

In deinem konkretem Fall würde ich keine Exceptions empfehlen. Das ist ein klarer Fall für das Logging. Anstatt bei jeder Wertprüfung sofort eine Meldung auszugeben oder eine Exception zu werfen, empfehle ich nur mit if() alle möglichen Prüfungen durchzugehen und die "nicht bestandenen" Prüfungen sammeln, z.B. in einer Liste. Nachdem alle Prüfungen erledigt sind, wird die Liste ausgewertet, dem User entsprechend formatiert und in einer JOptionPane ausgeben. So kann man gleich alle möglichen Fehler dem User auf einmal zeigen und er muss sich nicht von Fehler zu Fehler kämpfen.

Slawa

 

[Verjigorm]

Naja das Programm welches ich momentan bearbeite, ist nicht wirklich nach dem MVC-Prinzip aufgebaut, folgt eigentlich keinem erkennbarem Muster, nur Kraut und Rüben

Und die Idee mit der Liste von Fehlern:
Die Werte bauen aufeinander auf, wenn der "oberste" Wert falsch ist, sind alle folgenden auch falsch.

Eine andere Exception kann nicht auftreten, sind alles nur einfache Vergleiche und Additionen.

Die Eingabewerte können auch nicht falsch sein.

Die Methode mit der Exception bietet mir halt die Möglichkeit an einer zentralen Stelle Flags zu setzen, die für die Weiterverarbeitung hilfreich sind usw.

Ich hab das übrigends auf Java ist auch eine Insel aufgeschnappt:
http://www.galileodesign.de/openboo...08_003.htm#mj5a33d1a2fb38d8efe689a86438f29e2f