# Exceptionhandling: Richtige Verwendung des Try/Catch Blocks



## Final_Striker (10. Aug 2009)

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.


```
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
		}
	}
```


----------



## bygones (10. Aug 2009)

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....


----------



## maki (10. Aug 2009)

> 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


----------



## Final_Striker (10. Aug 2009)

Ok, das mit der java.lang.Exception war jetzt nur als Beispiel gedacht. Hab es jetzt oben ein wenig angepasst.


----------



## KrokoDiehl (11. Aug 2009)

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 

bei kleinen try-Blöcken finde dass sie die Lesbarkeit stören und
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.


----------



## Aske (11. Aug 2009)

maki hat gesagt.:


> 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.



Und was ist der genaue Grund dafür?


----------



## maki (11. Aug 2009)

Aske hat gesagt.:


> 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 (11. Aug 2009)

maki hat gesagt.:


> 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.
> ...



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


----------



## maki (11. Aug 2009)

Aske hat gesagt.:


> 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


----------



## tfa (11. Aug 2009)

Ich habe mal ein paar Sätze zum Thema Exceptions gebloggt:
http://www.java-forum.org/blogs/tfa/79-exceptions-frequently-asked-questions.html

Wenn das rund ist, kann man es ja in die FAQ verschieben.


----------



## Aske (11. Aug 2009)

maki hat gesagt.:


> [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.
> ...



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.


----------



## maki (11. Aug 2009)

Aske hat gesagt.:


> 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..


----------



## tfa (11. Aug 2009)

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 (11. Aug 2009)

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!


----------



## maki (11. Aug 2009)

Aske hat gesagt.:


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


Ja, sehe ich jetzt auch so, also Spass drüber & Schwamm beiseite


----------

