Junit Test erkennt Exception nicht..

[pun]

Bin grad echt ratlos...
Hier mal etwas Code...
Ihr müsst nicht viel lesen, nur soviel:
Die Bedingung, die die RuntimeException werfen soll, wird in einem JUnit Test offensichtlich erfüllt,denn ich bekomme über das sout meine Meldung ausgegeben ("RuntimeException")

[HIGHLIGHT="Java"]public static String expand(String input) throws RuntimeException {
String test="";

for (int i=0;i<input.length();i++) {
try {
final char chr = input.charAt(i);
/* Marker found! */
if (chr == 'Z') {
i++;
char zweiterchr = input.charAt(i);
if ((int)(zweiterchr) <48 || (int)(zweiterchr)>57) {
System.out.println("RuntimeException!");
throw new RuntimeException();

}
int counter = (int)(input.charAt(i)-'0'); // this one has to be of type counted


i++;
for (int j=0;j<counter;j++) { // repeat *counted* times
test += input.charAt(i); // this one has to be the compressed char
}
}
else // no marker found...return input
test += chr;
}
catch (Exception e) {
break; // end of string reached already !
}
}
return test;
}[/HIGHLIGHT]


Mein JUnit Test:
[HIGHLIGHT="Java"]@Test(expected=RuntimeException.class) public void expand5() {
RunlengthCompressor.expand("ZbB");
}[/HIGHLIGHT]

Dies hier ist der Test,der die Bedingung erfüllt, es wird auch "RuntimeException!" über sout ausgegeben...

Trotzdem erhalte ich immer den Fehler, dass die Exception, die erwartet wird, nicht kommt.
Warum nicht?

 

[Wildcard]

Du wirfst die Exception zwar, aber nicht nach aussen, da du sie selbst fängst.
[HIGHLIGHT="Java"] catch (Exception e) {
break; // end of string reached already !
}[/HIGHLIGHT]
Sowas tut man übrigens niemals! Exceptions dürfen nicht für die Programmsteuerung verwendet werden.

 

[0x7F800000]

Dies hier ist der Test,der die Bedingung erfüllt, es wird auch "RuntimeException!" über sout ausgegeben...

normalerweise sollte das programm sowas nicht über System.out ausgeben, ich hoffe das ist nur zu test?

Trotzdem erhalte ich immer den Fehler, dass die Exception, die erwartet wird, nicht kommt.
Warum nicht?

Wie denn? Die wird doch in Zeile 27 wieder verschluckt :autsch:

Sonstige bemerkungen:
1) omfg
2) RuntimeExceptions sollte man nicht selbst werfen
3) RuntimeExceptions sollte man auf keinen Fall abfangen, die sind dazu da um auf grobe Programmierfehler hinzuweisen, beim normalbetrieb sollten die nicht vorkommen
4) Man sollte auf gar keinen Fall einfach nur "Exception" abfangen
5) Exceptions sollte man jetzt wirklich nicht zur kontrolle des Programmflusses einsetzen. Ich könnte mich irren, aber imho. sollte da irgendein break auch schon reichen

 

[Wildcard]

2) RuntimeExceptions sollte man nicht selbst werfen

So nicht richtig

3) RuntimeExceptions sollte man auf keinen Fall abfangen, die sind dazu da um auf grobe Programmierfehler hinzuweisen, beim normalbetrieb sollten die nicht vorkommen

auch nicht richtig

 

[0x7F800000]

So nicht richtig

Ja, natürlich, sowas wie IllegalArgumentException und IndexOutOfBounds exception bei eigenen Datenstrukturen sollte man natürlich schon werfen, da hab ich ein wenig übertrieben, sorry.

auch nicht richtig

Wo man die abfangen sollte, kann ich mir grad irgendwie nicht vorstellen... Also, zumindest die oft auftretenden Vertreter wie ArithmeticException , ClassCastException , ConcurrentModificationException , IllegalArgumentException , IllegalStateException , IndexOutOfBoundsException , NegativeArraySizeException , NullPointerException , SecurityException , UnsupportedOperationException die will ich doch normalerweise ganz klar und deutlich in dicker roter schrift sehen, weil sie normalerweise darauf hinweisen, dass man mist gebaut hat :bahnhof: Oder nicht? ???:L

*jaja, Pauschalurteile ist was ausschließlich für Vollidioten, schon klar *

 

[Wildcard]

Deine Aussage deckt sich ein Stück weit schon mit der ursprünglichen Intention der Exceptions, aber die Checked Exceptions kamen ein wenig in Verruf und viele Experten raten mittlerweile eher dazu nur noch unchecked Exceptions zu verwenden. Egal welche Ansicht man persönlich vertritt (denn beide Ansätze haben Vor- und Nachteile), fakt ist, es wird heftig debattiert was der richtige Weg ist und solange es *den* richtigen Weg nicht gibt, musst du in jedem Fall beide Fälle berücksichtigen und unchecked Exceptions als gleichwertig behandeln.

 

[0x7F800000]

fakt ist, es wird heftig debattiert was der richtige Weg ist und solange es *den* richtigen Weg nicht gibt, musst du in jedem Fall beide Fälle berücksichtigen und unchecked Exceptions als gleichwertig behandeln.

Okay okay, dann ist meine 3) Aussage nicht als "absolute Wahrheit", sondern vielleicht als "tendentiell eher richtig" zu betrachten, damit könnte ich leben.

 

[Wildcard]

Okay okay, dann ist meine 3) Aussage nicht als "absolute Wahrheit", sondern vielleicht als "tendentiell eher richtig" zu betrachten, damit könnte ich leben.

Nun, was du tun musst, ist die Doku/Java-Doc der von dir verwendeten Libraries zu lesen und zu verstehen wie die Library Exceptions einsetzt. Anhand dessen, entscheidest du was man besser fängt, und was nicht.
Also: nicht blind auf das throws verlassen, sondern lesen was die Methode zu sagen hat und dann festlegen was du behandeln willst/kannst. RuntimeExceptions zu fangen ist völlig valide.

 

[pun]

Ich weiß, dass man nicht einfach jede Exception fangen sollte, die Zeile hab ich gar nicht mehr beachtet..
War nur ursprünglich so, dass ich nicht wusste welche Exception ich fangen will, als ich die Zeile geschrieben habe..

Und dass eine RuntimeException geworfen werden soll hab ich nicht willkürlich so gewählt, dass wollte unser Prof so..
Selbiges gilt für die Kontrolle des Programmablaufs..auch so gewollt.

Trotzdem danke für die Hilfe, das Problem war natürlich das Abfangen,was ich gar nicht mehr beachtet hatte...

/edit

jap das sout war nur zum test

 

[0x7F800000]

Und dass eine RuntimeException geworfen werden soll hab ich nicht willkürlich so gewählt, dass wollte unser Prof so..

protest.

 

[pun]

Die Klasse RunlengthCompressor definiert zwei statische Methoden, compress und expand . compress komprimiert Text optimal, ex pand expandiert ihn wieder. Beide Methoden akzeptieren einen String Parameter und liefern ein String Ergebnis. Sie werfen eine RuntimeException , wenn der übergebene String nicht den in der Grammatik festgelegten Aufbau hat.

So war das da gestanden

 

[0x7F800000]

Ja gut, so wie es da steht, sollen die methoden bei ungültigen Eingaben exceptions werfen, das ist ja Ok. Da steht halt nirgends, dass man exceptions als eine art goto missbrauchen sollte... Mach dieses "catch" aus deinem code weg, dann ist alles in Ordnung.

 

[Noctarius]

Ich weiß, dass man nicht einfach jede Exception fangen sollte, die Zeile hab ich gar nicht mehr beachtet..

Der Grund wieso man mit sowas (auch zum prototyping) garnicht erst anfangen sollte

 

[0x7F800000]

Der Grund wieso man mit sowas (auch zum prototyping) garnicht erst anfangen sollte

und wenn schon, dann sollte man da wenigstens ein TODO dranhängen, dass man das ja nicht vergisst und drinlässt...

 

[SlaterB]

3) RuntimeExceptions sollte man auf keinen Fall abfangen, die sind dazu da um auf grobe Programmierfehler hinzuweisen, beim normalbetrieb sollten die nicht vorkommen

es scheint mir noch nicht ganz deutlich geworden:
Ausnahme 1: RuntimeExceptions, die nicht Programmierfehler sind, wie HibernateExceptions und alle anderen User-definierten Exceptions, die 'freundlicherweise' unchecked sind, aber genauso abzufangen sind wie normale Exceptions

Ausnahme 2: selbst NullPointerExceptions & Co. sind an manchen zentralen Stellen abzufangen, etwa um sie zu loggen/ eine rote Lampe in der GUI blinken zu lassen,
ansonsten würde das etwa ein Thread selber bei seinem Abbruch als System.err ausgeben und das wars