try catch verschachtelt java

[Gandhi]

Hallo,
ist es möglich eine Verschachtelung derart einzubauen?
 
try{
//code
}
catch{
   try{
   //code
   }
   catch{
   //
   }
}

Zum Hintergrund:
Ich will einen Hostnamen in eine IP umwandeln. Steht der Rechner in einer Subdomäne, kann er nicht aufgelöst  werden und ich erhalte einen Fehler.
Da ich nur 2 Subdomänen habe könnte ich das logisch mit einem zweiten Versuch Hostname+Subdomain versuchen.

[flaite]

Ja klar. Anders bekommt man klassisch JDBC nicht hin. 

Gibt es nicht vielleicht irgendwelche anderen Möglichkeiten? Gibt es vielleicht eine Methode um zu prüfen, ob der host vorhanden ist?
Das ist schon ein hack. Dein Nachfolger rechnet nicht unbedingt damit, dass du exceptions so mißbrauchst. Auch aus Performance-Gesichtspunkten nicht das Gelbe.

klassisches jdbc:

Code

} catch (SQLException e) {
 logger.logException(); // hm.. pseudocode...
 try{
   if (con != null) con.close(); 
} catch (SQLException e) {}
} 

Die innere Exception ist die einzige Stelle, an der die leere Klammer i.O. ist (damit wird die Exception nirgendwo geloggt, normalerweise sehr schlechte Idee).

Das ist natürlich ziemlich unleserlich. Rod Johnson (springframework) hat das heftig kritisiert und in Spring braucht man das nicht.

[Gandhi]

Ja, es würde auch anders gehen - dazu müsste ich dann allerdings die Subdomäne aus der Registry auslesen.
Das Problem ist, dass die ganze Sache hier nicht sauber überall eingetragen zu sein scheint und ich selbst keine Möglichkeit habe eben mal nach Mailand zum Testen zu fahren (die Subdomänen sind geografische).
Meinen Nachfolger wird es unter Umständen hier auch nicht geben, da die hier eh aus politischen Gründen (also wider jede Vernunft) von Notes wegkommen wollen...aber das ist ein anderes Thema.

Vielen Dank jedenfalls erst mal für Deine Hilfe!

Viele Grüsse
Marco

[flaite]

hiermit könnte es Möglichkeiten geben, um zu checken, ob die url existiert, ohne dass eine exception geworfen wird:
http://jakarta.apache.org/commons/net/
(oder jakarta commons httpclient).

Genau um von solchen politischen Entscheidungen unabhängig zu sein, bin ich wie ich bin.
Auf der anderen Seite glaub ich, dass die TCO von solchen länger in die Zukunft reichenden Entscheidungen gar nicht auszurechnen sind (im Sinne von nicht möglich).

[Gandhi]

Naja, die TCO für die reine Migration liegt bei >10 Mio... ohne Gewinn von Funktion...
Manchmal fragt man sich dann doch, ob die Aktionärskultur da greift und irgendjemand auf der JHV fragt, wo denn der Nutzen einer Migration war, die >10 Mio gekostet hat...
Hoffentlich ist das der Fall. Auf die Antwort bin ich dann aber mal gespannt...

[flaite]

Naja, die TCO für die reine Migration liegt bei >10 Mio... ohne Gewinn von Funktion...

Kommt auf den Zeitraum der Abschreibung ab, wieviel das p.a. sind.

Der Markt ist eben in Bewegung. Ich bin hier auch den größten Teil meiner Zeit für ein Notes-Projekt in einem weitestgehend Java-geprägten Umfeld zuständig, was irgendwie auch sehr ironisch ist. Bin allerdings für Teile des Fußvolks auch ein etablierter Ansprechpartner in allen J2EE Fragen  (wenn wir gar nicht weiter wissen, fragen wir einfach den Notes Programmierer).
Für mich ist J2EE/.NET eine Flut, von deren Kraft, Dynamik und Ausmaß sich in diesem Forum sehr wenig5e Leute wirklich eine Vorstellung machen.