Exceptions - spiegeln wir da nicht einen Spiegel im Spiegel?

[guni]

Hallo,

ihr kennt das sicher, wenn man zwei Spiegel gegenüber hält ...
man sieht, wie sie sich bis ins Unendliche spiegeln ...

Jetzt mal rein philosophisch:
Ist das Konzept der Exceptions in Java nicht ähnlich?!
Ich hab folgenden Code:

try {
    // irgendein Code
} catch(Throwable t) {
    // Exception Handling Code
}

was macht Java denn, wenn ich in der Exception eine Exception hab ...
einfaches Beispiel:
ich hab eine Prozedur, die eine Verbindung zu SQL aufbauen soll ...
jetzt geh ich her und sag in der Funktion, dass ich den Fehler "konnte keine Verbindung zur Datenbank aufbauen" in eine Log-Tabelle in eben dieser Datenbank schreiben möchte ...
Was macht das Java dann?!

mfg, guni

 

[SnooP]

steigt aus.

du erstellst mit einem try/catch block keine Schleife - das catch fängt den im try-block auftretenen fehler... wenn in der Anweisung des catch-blogs "derselbe" oder ein anderer Fehler auftritt muss die anweisung die diese exception hervorrufen kann entweder wiederum in einem eigenen try-catch-block behandelt werden oder aber auch nicht... dann fällt java aber je nach exception-typ auf die Nase...

aber richtig: es macht nicht viel sinn in einem catch der einen Datenbankverbindungsfehler fängt einen Eintrag in die selbe DB zu machen...

 

[SlaterB]

Java macht da gar nix,

wenn man selber dran denkt und spiegeln will, dann

try {
    // irgendein Code
} catch(Throwable t) {
  try {
    // Exception Handling Code
  } catch(Throwable t) {
     // noch mehr Exception Handling Code
  }
}

ansonsten ist es auch durchaus nicht völlig abwegig, dass ein solcher Fehler dann eben nicht behandelt wird,
siehe Webseiten wie diese hier, bei denen bei bösen Grundlagen-Fehlern durchaus auch mal SQL-Fehlermeldungen direkt im Brower erscheinen,
evtl. HighLevel abgefangen und durch eine allgemeine Fehler-Nachricht ersetzt

 

[maki]

Was macht das Java dann?!

Eine Exception werfen, aber bestimmt eine andere

Dein Vergleich hinkt übrigens gewaltig..

 

[musiKk]

Nervig ist das aber trotzdem manchmal. Wenn man eine IOException (wie auch immer geartet) hat und im finally- oder catch-Block z. B. einen Stream schliessen moechte, muss man wieder eine IOException fangen. Wenn die kommt, kann man ja wirklich nur noch mit den Schultern zucken. Gerade, wenn es I/O-Probleme gibt, und man vielleicht nichtmal mehr eine Log-Meldung in eine Datei schreiben kann.

 

[maki]

Das nervige daran sind checked Exceptions

 

[guni]

@musikK: genau daran häng ich grad ... aber da kann man wohl nichts mehr machen ...
muss sich der User eben damit abfinden, dass er den Fehler selbst finden muss, wenn das Prog nichtmal mehr logt ...
@maki: wieso hinkt denn mein Vergleich? ich find den gut ;-) ... in beiden Fällen geht es doch um eine Rekursion!

 

[musiKk]

Um mal dazwischenzureden: Nein, es ist keine Rekursion. Ein try-catch-Block ist nur fuer genau eine Exception da. Alle weiteren Exceptions, die waehrend der Behandlung auftreten, muessen eigene try-catch-Bloecke bekommen. Das wurde aber oben auch schon erlaeutert.

Und du kannst da wirklich nichts machen. Aber da muesste man ja auch zaubern koennen... Wenn was kaputt ist, dann ist halt was kaputt... mit allem, was das noch nach sich zieht.

 

[maki]

Eine Exception im catch Block ist keine Rekursion

Abgesehen davon ist throwable zu catchen bis auf wenige Ausnahmen sehr sehr falsch...

Try/catch Blöcke in Try/catch Blöcken sieht echt doof aus, jeder der mal mit DBC entwickelt hat kennt das.

 

[Guest]

das gibt ne Rekursion:

public void doWhatIWant(){
    try {
        throw new IDontThinkSoException();
    } catch (IDontThinkSoException ex){
        doWhatIWant();
    }
}

aber rein innerhalb von try/catch geht sowas net imho

 

[musiKk]

Wer sowas programmiert, hats aber auch nicht besser verdient.