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:
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....
 
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 🙂
 
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.
 
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.
 
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:
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 😉
 
[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:
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:
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.
 
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.

Neue Themen


Zurück
Oben