Catch Block in Try erzwingen

[NT2005]

Hallo Community,

Ich habe eine wohl sicherlich abwegige Frage und zwar würde ich gerne unter einer bestimmten Bedingung einen Fehler im try produzieren damit ich auf jedenfall in den catch lande.

try {
String name = ReadLine();

// Hier sind noch andere Methoden drinnen, die Fehler produzieren können...

if(line.equals("bla")) {
// mach das
} else if(line.equals("quark") {
// mach jenes
} else {
// Hier soll ein fehler vorgetäucht werden
// da dieser in der Catch-Methode behandlet werden soll
}

} catch (Exception e) {
//Error handling
....
System.out.println("....")
}

Wie kann ich einen Error vortäuchen?

 

[tfa]

[c]throw new Exception();[/c]?

Ist das nur eine Frage oder willst du das wirklich so machen?

 

[Volvagia]

Theoretisch ginge auch

Object obj = null;
obj.hashCode();

Nicht so schön aber irgendwie lustiger. (Wenn man bei soetwas von "schön" sprechen kann.)
Wird dir aber wohl eine Warnung generieren.

Wenn du einen Block willst in dem immer gesprungen wird kannst du einen finally anhängen.

 

[thewulf00]

Theoretisch ginge auch

Object obj = null;
obj.hashCode();

Wenn man sowieso schon so ein abgekartetes Spiel treibt, dann doch lieber in aller Kürze:

((Object)null).hashCode();

 

[beastofchaos]

Wieso willt du daraus ein Error machen? Anstatt das direkt in dem else{ }- Block zu schreiben? Den Unterschied sieht man nur als Programmierer, aber das Programm verhält sich schließlich gleich, wobei eine Exception absichtlich zu werfen mir doch sehr unschön scheint 😀
Wenn du das machst, weil das öfters aufgerufen wird, dann mach halt ne extra Methode 😉 (aber ich kann ja deinen Willen leider nicht lenken^^)

 

[faetzminator]

[...] wobei eine Exception absichtlich zu werfen mir doch sehr unschön scheint 😀

Exceptions werden immer absichtlich geworfen 😉 Aber warum man eine Exception werfen sollte, welche man selber wieder in der gleichen Methode abfängt... das ist wirklich etwas sinnfrei 😀

 

[navas]

Exceptions werden immer absichtlich geworfen 😉 Aber warum man eine Exception werfen sollte, welche man selber wieder in der gleichen Methode abfängt... das ist wirklich etwas sinnfrei 😀

Nicht unbedingt. Unter folgenden Umständen macht es Sinn:
- Grössere Codeblock, try/catch-Block darum
- Der Code nach einer geworfenen Exception soll nicht ausgeführt werden und im Catch-Block soll immer dasselbe ausgeführt werden (z.B. Fehlermeldung auf GUI anzeigen)

 

[ARadauer]

einen Fehler im try produzieren damit ich auf jedenfall in den catch lande

ist es ein eichter Fehler muss du einfach eine Execption werfen.
Testest du nur dein Fehlerhandling, da mach ich immer ein int x = 1/0;

 

[tfa]

Nicht unbedingt. Unter folgenden Umständen macht es Sinn:
- Grössere Codeblock, try/catch-Block darum
- Der Code nach einer geworfenen Exception soll nicht ausgeführt werden und im Catch-Block soll immer dasselbe ausgeführt werden (z.B. Fehlermeldung auf GUI anzeigen)

Klingt irgendwie unsauber. Benutzt du hier Exceptions um den Programmfluss zu steuern?

 

[Tomate_Salat]

Wenn jz in deinem Code dummerweise eine Exception fliegt, wo du keine erwartet hättest, dann landest du auch im Catch-Block und dein Codefluss stimmt nicht. Wie bereits gesagt: entweder extra Methode oder den Code in den else-Teil schreiben.

Exceptions schmeist du dann, wenn du an der aktuellen Stelle die Problematik nicht behandeln kannst(willst). Der Programmierer, der später deine Methode anwendet, muss sich dann eben darum kümmern, diese richtig zu behandeln.

 

[navas]

Klingt irgendwie unsauber. Benutzt du hier Exceptions um den Programmfluss zu steuern?

Wenn ich irgendwo einen Fehler werfe, dann passiert gar nichts, nur die Fehlermeldung wird angezeigt

try{
if({Ausdruck der false ergibt}){
    throw new IllegalArgumentException("Fehler");
}

if({Ausdruck der false ergibt}){
    throw new IllegalArgumentException("Fehler");
}
...

//query ausführen
} catch (IllegalArgumentException e) {
     MessageUtil.addErrorString(req, e.getMessage());
}

In diesem Code wird sonst nirgends eine IllegalArgumentException() geworfen. Der Code ist komplexer als hier dargestellt, d.h. mehrere if/else verschachtelt.

 

[tfa]

Ein klassisches Beispiel, was man mit Exceptions nicht machen sollte.

In diesem Code wird sonst nirgends eine IllegalArgumentException() geworfen.

Da kann man sich nie so sicher sein. Wenn nicht jetzt, dann vielleicht in 3 Monaten...

Der Code ist komplexer als hier dargestellt, d.h. mehrere if/else verschachtelt.

Das ist von vorn herein schlecht. "Größere Codeblöcke" soll man vermeiden -- besonders, wenn man viele
verschachtelte Bedingungen hat. Spalte das in mehrere kleine Methoden auf. z.B. eine Check-Methode, die
die Bedingungen überprüft und ggf. eine Meldung ausgibt und eine Methode die ansonsten die Berechnung durchführt.
Dann brauchst du keine unübersichtliche Exception-Werferei für den Kontrollfluss.

 

[SlaterB]

in wirklich komplexen Ebenen kann man Exceptions durchaus einsetzen,
ähnlich wie Hibernate bei einer SQLException nichts anzufangen weiß

verschiedene Klassen, verschachtelte Methodenaufrufe sollten es aber schon sein, nicht nur innerhalb einer Methode

was ich eigentlich anmerken wollte: gegen falsche Interpretation hilft eine eigene Exception-Klasse, AbortException oder ähnlich

 

[Tomate_Salat]

@navas:
Ein solches Konstrukt ist gefährlich und es kann schnell außer Kontrolle geraten. Dafür reicht eine Methode, die diese Exception werfen kann.

 

[NT2005]

Danke für die vielen Antworten, habe heute in der Uni darüber nachgedacht und eine wohl eindeutig bessere Methode über finally mit Bedingung gefunden. 😉 Danke dennoch für die angenehme Diskussion. 😉