Exceptionhandling: Richtige Verwendung des Try/Catch Blocks

Status
Nicht offen für weitere Antworten.

Final_Striker

Top Contributor
Hallo,
bin am Programmieren und habe mich gerade gefragt, wie ich einen Try/Catch Block am sinnvollsten platziere.
Hab jetzt mal 3 Beispiele aufgeführt. Welche Methode wäre die bessere/saubere Lösung oder gibt es vllt. auch noch eine andere bessere.

Java:
	public void method1()
	{
		try{
			TestClass t = getStream(); // Methode wirft Exception
			t.doSomething();
			t.doMoreSomething();
		}
		catch (MeineException e){
			// handle Exception
		}
		... // weiterer Code
	}
	
	public void method2()
	{
		TestClass t;
		
		try{
			t = getStream(); // Methode wirft Exception
		}
		catch (MeineException e){
			// handle Exception
		}
		
		t.doSomething();
		t.doMoreSomething();
		... // weitere Code
	}
	public void method3()
	{
		try{
			TestClass t = getStream(); // Methode wirft Exception
			t.doSomething();
			t.doMoreSomething();
			... // weitere Code
		}
		catch (MeineException e){
			// handle Exception
		}
	}
 
Zuletzt bearbeitet:
B

bygones

Gast
wuesste kein generelles How To.

ich bin eher dafuer die Exception an den Aufrufer zu geben ( bzw als Runetimeexception zu verpacken) anstatt sie irgendwo tief in der logik zu fangen....
 
M

maki

Gast
wuesste kein generelles How To.
Eben, aber es gibt generelle How-Not_to, dazu gehört dass man niemals [c]java.lang.Exception[/c] selbst fangen sollte (mit ein paar Ausnahmen natürlich), sondern konkrete Exceptions.

ich bin eher dafuer die Exception an den Aufrufer zu geben ( bzw als Runetimeexception zu verpacken) anstatt sie irgendwo tief in der logik zu fangen....
Find ich gut :)
 

KrokoDiehl

Top Contributor
Dazu kann ich auch nur sagen, was ich mir angewöhnt habe: Und zwar die 'ganz-oder-gar-nicht'-Lösung (deine method3), weil ich
  1. bei kleinen try-Blöcken finde dass sie die Lesbarkeit stören und
  2. bei großen try-Blöcken finde, dass Anweisungen davor und danach verschwinden (bzw. eher übersehen werden).
Aber das ist sicher Ansichtssache und es gibt 100%ig auch Fälle, wo es anders geschrieben werden muss.
 
M

maki

Gast
Und was ist der genaue Grund dafür?
Wie will man denn sinnvoll auf alle möglichen Arten von Exceptions reagieren können?
-> gar nicht

Es macht nur in Ausnahmefällen Sinn, alle Exceptions gleich zu behandeln, normalerweise gilt der Grundsatz: Je genauer, umso besser.

Die Exceptions die man nicht erwartet, sind meist ein Programmierfehler, und die einzig richtige Reaktion auf einen Programmierfehler ist den Fehler zu beseitigen und nicht zu versuchen damit "umzugehen", denn letzteres kann ja nicht klappen.
 

Aske

Mitglied
Wie will man denn sinnvoll auf alle möglichen Arten von Exceptions reagieren können?
-> gar nicht

Es macht nur in Ausnahmefällen Sinn, alle Exceptions gleich zu behandeln, normalerweise gilt der Grundsatz: Je genauer, umso besser.

Die Exceptions die man nicht erwartet, sind meist ein Programmierfehler, und die einzig richtige Reaktion auf einen Programmierfehler ist den Fehler zu beseitigen und nicht zu versuchen damit "umzugehen", denn letzteres kann ja nicht klappen.

Aber es kann doch nicht verkehrt sein, um seine ganze Methode zumindest zusätzlich ein try catch zu machen, error und exceptions zu fangen und diese zu protokollieren.

Das macht bei 90% aller Programme der Welt Sinn, nämlich Batchroutinen :)
 
Zuletzt bearbeitet:
M

maki

Gast
Aber es kann doch nicht verkehrt sein, um seine ganze Methode zumindest zusätzlich ein try catch zu machen, error und exceptions zu fangen und diese zu protokollieren.
[c]]java.lang.Error[/c] (bzw. [c]java.langThrwoable[/c]) zu fangen ist zu 99% ein Fehler, da gelten noch strengere Regeln als für [c]java.lang.Exception[/c].
Wie würdest du denn mit einem OutOfMemoryError umgehen? Kann dann noch etwas ins Log geschrieben werden, wenn der Hauptspeicher voll ist? ;) Leider nicht deterministisch...

Exceptionhandling sollte man auf die erwarteten und sinnvollen Exceptions beschränken, zB einen NullPointerException zu fangen ist fast immer daneben, weil diese fast ausschliesslich durch Programmierfehler entstehen.

Das macht bei 90% aller Programme der Welt Sinn, nämlich Batchroutinen
Nein, weil diese meist auf einem Server laufen, der sowieso mitloggt.

Halte deinen Code am besten Frei von sinnlosem Code, dann wird dieser meist besser ;)
 

Aske

Mitglied
[c]]java.lang.Error[/c] (bzw. [c]java.langThrwoable[/c]) zu fangen ist zu 99% ein Fehler, da gelten noch strengere Regeln als für [c]java.lang.Exception[/c].
Wie würdest du denn mit einem OutOfMemoryError umgehen? Kann dann noch etwas ins Log geschrieben werden, wenn der Hauptspeicher voll ist? ;) Leider nicht deterministisch...

Exceptionhandling sollte man auf die erwarteten und sinnvollen Exceptions beschränken, zB einen NullPointerException zu fangen ist fast immer daneben, weil diese fast ausschliesslich durch Programmierfehler entstehen.


Nein, weil diese meist auf einem Server laufen, der sowieso mitloggt.

Halte deinen Code am besten Frei von sinnlosem Code, dann wird dieser meist besser ;)

Ich weiß ja nicht ob Du beruflich als Entwickler arbeitest, aber ein Kunde würde mir was anderes erzählen, wenn ein Programm irgendwo mit einer Exception abfliegt und diese nicht protokolliert wird. Exceptions nicht zu fangen ist meiner Meinung nach eine theoretische Lehre, die in der praktischen Anwendung selbst nichts zu suchen hat.
Und einen OutOfMemoryError zu fangen ist schlichtweg egal (klar kann das Programm nichts mehr machen), aber nicht falsch.
 
Zuletzt bearbeitet:
M

maki

Gast
Ich weiß ja nicht ob Du beruflich als Entwickler arbeitest, aber ein Kunde würden mir was anderes erzählen, wenn ein Programm irgendwo mit einer Exception abfliegt und diese nicht protokolliert wird. Exceptios nicht zu fangen ist meiner Meinung nach eine theoretische Lehre, die in der praktischen Anwendung selbst nichts zu suchen hat.
Und einen OutOfMemoryError zu fangen ist schlichtweg egal (klar kann das Programm nichts mehr machen), aber nicht falsch.
Denke nicht das es der Diskussion hilft persönlich zu werden und/oder die Kompetenz des Gegenübers in Frage zu stellen.

Ja, seit über 9 Jahren arbeite ich als Entwickler.
Bis jetzt habe ich jede Exception in einem Log wiedergefunden, und Kunden haben sich darüber auch nicht beschwert.

Edit: wir meinen schon dasselbe..
 
Zuletzt bearbeitet von einem Moderator:

tfa

Top Contributor
Ich glaub ihr seid euch einig. Exceptions werden natürlich nie verschluckt und irgendwann auch geloggt. Nur eben zentral und so spät wie möglich, und nicht überall im Code verstreut.
 

Aske

Mitglied
ja, wir sind uns einig, haben nur aneinander vorbeigeredet :). Und Kompetenzen wollte ich zu keiner Zeit in Frage stellen.

Dein Exception Blog ist übrigens sehr gut!
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
lougoldi ExceptionHandling mit Optional<> Allgemeine Java-Themen 9
T ExceptionHandling mit bescheidenem Quellcode Allgemeine Java-Themen 14
2 Exceptionhandling Allgemeine Java-Themen 6
B Lottospiel, genug Reihen tippen für 3 Richtige (Spaß mit Arrays)? Allgemeine Java-Themen 46
N Ist Selenium hier das richtige Werkzeug? Allgemeine Java-Themen 1
F Java Script für das Vorhaben das richtige? Allgemeine Java-Themen 9
B Logikfehlersuche, das perfekte Lottosystem für 3 Richtige mit Arraylists? Allgemeine Java-Themen 61
F Java die richtige Sprache? - Anfänger Allgemeine Java-Themen 3
T If Vergleich ergibt nicht das richtige Ergebnis Allgemeine Java-Themen 2
U Welches ist das richtige Entwurfsmuster Allgemeine Java-Themen 2
P Richtige Verwendung eines Timers Allgemeine Java-Themen 8
L Richtige Dokumentation eines Java Programms Allgemeine Java-Themen 5
J JSP die richtige Wahl Allgemeine Java-Themen 2
P Ist Java überhaupt das Richtige für mich? Allgemeine Java-Themen 7
G "Richtige" Konsolenanwendung (wie z.B. nano, cente Allgemeine Java-Themen 4
B Java, Ant und das richtige JDK? Allgemeine Java-Themen 9
T Ist IAdaptable die richtige Lösung? Allgemeine Java-Themen 4
O Oberfläche und "richtige" Programmierung Allgemeine Java-Themen 8
L Welche Collection ist die richtige ? Listen mergen Allgemeine Java-Themen 3
K Richtige JVM für jar Ausführung? Allgemeine Java-Themen 4
meez Vectoren vs. "richtige" Arrays Allgemeine Java-Themen 18
Z JNA Cpp-DLL String Verwendung Allgemeine Java-Themen 2
M WSDL: Doppelte Typenames (Keine Verwendung möglich) Allgemeine Java-Themen 5
F Klassen Verwendung abstrakter Klassen Allgemeine Java-Themen 9
K Saubere Verwendung von Generic Types Allgemeine Java-Themen 7
D Verwendung von Selenium Allgemeine Java-Themen 2
P ClassCastException bei Verwendung eines Interfaces Allgemeine Java-Themen 7
M Fehler bei Verwendung von TexturePaint Allgemeine Java-Themen 16
S OOP Apache Commons Math - Verwendung von Genetics - Wie werden Daten in Chromosomen gespeichert? Allgemeine Java-Themen 4
M Verwendung der Cipher von gnu crypto (Serpent) Allgemeine Java-Themen 3
B Verwendung von Packages im Java Code Allgemeine Java-Themen 10
T Warnungsfreie Verwendung von Generics Allgemeine Java-Themen 11
M Problem bei der Verwendung von AES Allgemeine Java-Themen 2
J Port verwendung Allgemeine Java-Themen 13
M Verwendung von unchecked exceptions & bereits vorhandenen exceptions was priorisieren Allgemeine Java-Themen 3
X Wie 'teuer' ist die Verwendung des Stack Trace ? Allgemeine Java-Themen 8
W Verwendung von byte Allgemeine Java-Themen 9
L Verwendung? Allgemeine Java-Themen 2
D Fehlerhafte Thread Verwendung beim arbeiten mit Sockets Allgemeine Java-Themen 6
N allg. Frage zur Verwendung von this Allgemeine Java-Themen 3
G Verwendung von DataInputStream und URL Allgemeine Java-Themen 2
C Seltsame Konstanten (und Verwendung) Allgemeine Java-Themen 15
X Exception bei Verwendung von systray4j Allgemeine Java-Themen 5

Ähnliche Java Themen

Neue Themen


Oben