# try->catch->weitermachen



## jeipack (27. August 2008)

Hi
gibt es eine Möglichkeit nachdem man im catch-Block einen Fehler abgefangen hat an der nächsten Stelle weiter zu machen an der man aufgehört hat?

Pseudocode:

```
try {
System.out.println(a.get(1).getName()); //1
System.out.println(a.get(2).getName()); //2 ich werfe eine NullPointerException
System.out.println(a.get(3).getName()); //3
System.out.println(a.get(4).getName()); //4
System.out.println(a.get(5).getName()); //5

} catch(NullPointerException ex) {
System.out.println("Da war ein Fehler...");
//weitermachen bei 3
}
```

Klar könnte ich auch jede einzelne Anweisung in einen try-catch-Block verpacken aber 1. Mühsam und 2. wird der Code dadurch nicht übersichtlicher..
In diesem speziellen Fall könnte ich auch alles erst auf null überprüfen und dann getName() aufrufen -> Auch Mühsam und darauf will ich sowieso nicht hinaus..

Grüsse und danke
Hoffe es geht ihrgendwie


----------



## Matze (27. August 2008)

So etwas ist mir jetzt nicht bekannt, aber vieleicht kannst du ja mit finaly etwas anfangen.
try -> catch -> final
Der final-Block wird nämlich auf jedenfall bei einer Exception noch ausgeführt.


----------



## Leroux (27. August 2008)

Fang einfach nicht mit try->catch ab
kannst als alternative auch auf 

```
if( obj == Null)
```

und dann halt überspringen

vllt noch in eine Schleife rein wenn dies Möglich ist

mfg


----------



## zerix (27. August 2008)

Hallo,

wenn du es so machst wird es nicht funktionieren. Du müsstest in jeder Zeile ein try/catch drum bauen. Da wäre aber eine If-Anweisung wesentlich sinnvoller.


MFG

Sascha


----------



## Matze (27. August 2008)

@Leroux
Eben jenes will er vermeiden (siehe seinen Post) 
Auch wenn ich mir nicht vorstellen kann, wie das gehen soll.


Edit: Ups zu langsam... 60 Sekunden Warten nach letztem Post


----------



## Adrian_Broher (27. August 2008)

jeipack hat gesagt.:


> In diesem speziellen Fall könnte ich auch alles erst auf null überprüfen und dann getName() aufrufen -> Auch Mühsam und darauf will ich sowieso nicht hinaus..



Dann sorg dafür das keine Null Referenzen in die "a" Liste reinkommen können.


----------



## Billie (27. August 2008)

```
for(int i = 1; i <= 4; i++) {
  try {
    System.out.println(a.get(i).getName());
  } catch(Throwable t) {
    t.printStackTrace();
  }
}
```

Kommt darauf an, wo du das wirklich verwenden willst... wirklich beim iterieren durch eine Liste?!


----------



## Anime-Otaku (27. August 2008)

IMO sollten Exceptions nur geworfen werden, wenn auch wirkich ein Fehler vorliegt.

RuntimeExceptions (also Nullpointer, NumberFormat;ArrayIndexOutofbounds.....) jedoch sollten nie fliegen, da man diese durch Überprüfung verhindern kann.

Also entweder sorgst du dafür, dass kein Null in der Liste steht oder du überprüfst es vorher mittels if. (am einfachsten in einer Schleife)


```
for(int i = 0; i < a.size(); i++) {
   Object tmp = a.get(i);
if(tmp!=null)
{
System.out.println(a.get(i).getName());
}
else{
//log Ausgabe oder counter wieviel null sind oder oder
}
          
      }
```

P.S.: der Index einer Liste beginnt bei 0


----------



## Oliver Gierke (27. August 2008)

Anime-Otaku hat gesagt.:


> RuntimeExceptions (also Nullpointer, NumberFormat;ArrayIndexOutofbounds.....) jedoch sollten nie fliegen, da man diese durch Überprüfung verhindern kann.


Exceptions sollten grundsätzlich nie fliegen, deshalb sind sie Ausnahmen . Irgendwie macht der Satz aber auch insgesamt keinen Sinn. Eigentlich ist das Gegenteil der Fall. RuntimeExceptions sind eigentlich End of the world Szenarien (DBConnection weg usw.), d.h. man will nicht überall explizit drauf reagieren, sondern diese zentral irgendwo fangen.

Im übrigen ist Java die einzige populäre Sprache in der es überhaupt checked Exceptions gibt.

Zum Code des Originalposters: ich halte diese Art, eine Liste zu durchsuchen für Unfug. Eine foreach Schleife um die Liste herum, eine null-Prüfung und du bist glücklich. NPEs gehören nicht gecatcht. NPEs sind Programmierfehler, also End of the World Szenarien.

Gruß
Ollie


----------



## jeipack (27. August 2008)

Hi Leute
Hab wieder Zeit, war recht beschäftigt. MySQL Server bockte rum --> http://www.tutorials.de/forum/linux-unix/322147-debian-mysqld-sock.html

Also erstmal vielen Dank für all die Antworten. 

"Kommt darauf an, wo du das wirklich verwenden willst... wirklich beim iterieren durch eine Liste?!"
--> Nein  Es war nur Democode. Ich weiss dass man mit ner forschleife durch eine Liste geht.. und auch dass man es erst auf Null prüfen kann oder um jeden einzelnen einen try-catch-Block machen könnte. Da das ganze aber für einen Prototyp ist (und ein _bisschen_ mehr als nur 5 Anweissungen überprüft werden müssten) wollte ich mir den Aufwand einfach ersparen..


Na gut
Danke trozdem
jeipack


PS: In VBA gibts sowas 


Edit: Ahja final bringt nicht viel, da ich ja wissen müsste wo der Fehler auftrat und dann zur nächsten Anweisung zurückspringen müsste.


----------



## Oliver Gierke (27. August 2008)

Nochmal: dafür sind Exceptions nicht gedacht. Was du versuchst ist quasi ein Konzept zu vergewaltigen . D.h. ifs sind an dieser Stelle die richtige wahl. Wenn du immer die gleiche Bedingung überprüft macht eine Schleife darum Sinn. Wenn es verschiedene Bedingungen sind und diese Arg viel werden, stellt sich die Frage, ob deine Methode vielleicht nicht ein bisschen zu viel macht.

Gruß
Ollie


----------



## Anime-Otaku (27. August 2008)

Oliver Gierke hat gesagt.:


> Exceptions sollten grundsätzlich nie fliegen, deshalb sind sie Ausnahmen .



Da stimme ich dir zu.



Oliver Gierke hat gesagt.:


> Irgendwie macht der Satz aber auch insgesamt keinen Sinn. Eigentlich ist das Gegenteil der Fall. RuntimeExceptions sind eigentlich End of the world Szenarien (DBConnection weg usw.),



Ich glaube du missverstehst mich. Ich meine eine RuntimeException im Sinne von der Java Klasse RuntimeException. Daher eine unchecked Exception, also eine welche man nicht explizit behandeln *muss* (mit try/catch oder mittels throw weiter werfen), damit der Code kompilierbar ist.
Diese kann man oftmals durch if Überprüfungen verhindern.


----------



## Oliver Gierke (27. August 2008)

Du hast oben geschrieben, dass man RuntimeExceptions durch Überprüfung verhindern kann. Das ist halt nicht immer richtig. Im Gegenteil - RuntimeExceptions sind eigentlich dazu da, Ausnahmefälle zu modellieren, die den Namen eigentlich richtig verdienen.

Ein gutes Beispiel sind die DataAccessExceptions von Spring. Datenbankzugriffsexceptions sind grundsätzlich erstmal zur Programmlaufzeit nicht zu beheben (oder wie willst du auf ein fehlerhaftes SQL Statement zur Laufzeit beheben?). Man muss beim Exceptiondesign das Programm zur Laufzeit des Users im Kopf haben, um diesen Unterschied zu verstehen. Während du entwickelst, kannst du den Fehler durch einen Fix beheben - klar. Beim Kunden aber ist ein SQL Fehler ein Bug. Daher ist es auch unsinnig um einen JDBC Call ein try catch für die Exception zu machen, die diese Exception fängt, weil: was willst du sinnvolles in den Catch Block schreiben? Im Gegenteil, du willst da eigentlich gar keine Exception fangen müssen. Deshalb -> RuntimeException.

Wie man sieht ist das Thema Exceptions kein triviales. Für mehr Infos empfehle ich:

http://www.se-radio.net/podcast/2006-02/episode-7-error-handling
http://www.se-radio.net/podcast/2006-07/episode-21-error-handling-pt-2

REINHAUN!


----------



## jeipack (28. August 2008)

Oliver Gierke hat gesagt.:


> Nochmal: dafür sind Exceptions nicht gedacht. Was du versuchst ist quasi ein Konzept zu vergewaltigen .


Genau 



Oliver Gierke hat gesagt.:


> D.h. ifs sind an dieser Stelle die richtige wahl. Wenn du immer die gleiche Bedingung überprüft macht eine Schleife darum Sinn. Wenn es verschiedene Bedingungen sind und diese Arg viel werden, stellt sich die Frage, ob deine Methode vielleicht nicht ein bisschen zu viel macht.


Ist nicht die gleiche Bedingung... Sonst hätte ich natürlich ne Schleife..
Mir ist schon klar was du mir sagen willst, da es sich aber um Code handelt den ich nachher wegwerfe bemühe ich mich nicht um sauberes programmieren oder gutes error handling.

Aber ich habs inzwischen 

Grüsse


----------

