Try - Catch

districon

Bekanntes Mitglied
Hallo,

ich versuche gerade ein paar Fehlermeldungen abzufangen und dafür Zahlenwerte auszugeben.

Java:
public int rate(String z) {
        int wert = 0;
        try {
            zahlenRaten.rate(z);
        } catch (InterruptedException a){
            wert = 1;
        } catch (java.util.ServiceConfigurationError b) {
            wert = 3;
        } catch (IllegalStateException c) {
            wert = 2;
        } catch (NumberFormatException d) {
            wert = 4;
        } catch (ZahlUngueltig e) {
            wert = 5;
        } catch (ZahlGueltigAberZuKlein f) {
            wert = 6;
        } catch (ZahlGueltig g) {
            wert = 7;
        } catch (ZahlGueltigAberZuGross h) {
            wert = 8;
        }
        return wert;
    }

Nur zeigt es mir bei ZahlGueltigAberZuKlein, ZahlGueltig und ZahlGueltigAberZuGross an:
Exception '....' has already been caught.
ZahlGueltigAberZuKlein und ZahlGueltigAberZuGross sind Unterklassen von ZahlGueltig und ZahlGueltig ist eine Unterklasse von InterruptedException. Kann mir jemand sagen was ich da verändern muss damit dieser Fehler nicht mehr kommt?
 
ZahlGueltigAberZuKlein und ZahlGueltigAberZuGross sind Unterklassen von ZahlGueltig
Das wird ja auch als "ist ein" Beziehung benannt. ZahlGueltigAberZuGross ist eine ZahlGueltig Exception. Damit wird das catch auf ZahlGueltig auch Exceptions abfangen die davon abgeleitet sind.

Die Regel hier ist also einfach: Immer erst die speziellen Exceptions abfangen und dann die generelleren. Oder direkt auf Deinen Code bezogen: Das Catch auf ZahlGueltig muss nach den davon abgeleiteten Exceptions geprüft werden.
 
Das wird ja auch als "ist ein" Beziehung benannt. ZahlGueltigAberZuGross ist eine ZahlGueltig Exception. Damit wird das catch auf ZahlGueltig auch Exceptions abfangen die davon abgeleitet sind.

Die Regel hier ist also einfach: Immer erst die speziellen Exceptions abfangen und dann die generelleren. Oder direkt auf Deinen Code bezogen: Das Catch auf ZahlGueltig muss nach den davon abgeleiteten Exceptions geprüft werden.
Ja macht Sinn. Jedoch hat sich noch nichts verändert. Es kommt immer noch die selbe Fehlermeldung
 
Wie sieht jetzt der Code genau aus? Und was ist die genaue Fehlermeldung? Vermutlich trifft dieses Problem noch auf weitere deiner Exceptions zu.

An der Stelle aber auch noch der Hinweis: Das Programm sollte nicht durch Exceptions gesteuert werden.
 
Wie sieht jetzt der Code genau aus? Und was ist die genaue Fehlermeldung? Vermutlich trifft dieses Problem noch auf weitere deiner Exceptions zu.

An der Stelle aber auch noch der Hinweis: Das Programm sollte nicht durch Exceptions gesteuert werden.
Der Fehler kam durch die InterruptedException. Ich hab den Catch-block mal ausgeklammert und jetzt funktioniert es
 
Wie sieht jetzt der Code genau aus? Und was ist die genaue Fehlermeldung? Vermutlich trifft dieses Problem noch auf weitere deiner Exceptions zu.

An der Stelle aber auch noch der Hinweis: Das Programm sollte nicht durch Exceptions gesteuert werden.
Diesen Fall müsste ich auch noch irgendwie abcatchen: "wenn gar nichts bekannt ist, weil gar nichts passiert ist und gar nichts zurückkommt". Gibt es dafür eine Exception, bzw wie soll ich das in meinen Codeblock einbauen?
 
Du könntest alle Exceptions fangen und im catch-Block anhand einer Map Exception-Klasse zu Nummer die Nummer setzen.
Natürlich musst Du auch auf die null reagieren, welche die Map bei unbekannter Exception liefert.

Letzten Endes erfolgt der Zusammenbau der Map auch im Code, das heisst, die Exceptions müssen bekannt sein.

Das ist nicht wirklich eine Lösung für:
wenn gar nichts bekannt ist

Dann eben die Map anhand einer Datei zusammenbauen.

Aber letztendlich ist dies nach meiner Meinung nicht lösbar.

Mich hat mal jemand wegen meinem Codegenerator für Fluent Interface angerufen.

Der wollte für Gremlin (Abfrage-Sprache für NoSql-Datenbanken) fluent interfaces machen, also letztendlich Typ-Prüfung und Code-Generierung aber für Dinge, die dynamisch erst zur Laufzeit bekannt sind.

Nun ja, Träume sind Schäume.
 
Was mich mal interessieren würde: warum?
Das bringt z.B. in DOS/Windows Batchaufrufen was, wenn du nach Ausführung des Programms den Errorlevel abfragen willst (System.exit(errorlevel)). 0 steht dabei normalerweise für "alles ok", alles andere muss definiert werden.

Ich würde das Ganze aber anders angehen, ein Throwable abfangen und dann (z.B. mit instanceof) prüfen, um welche Exception es sich handelt.
So wie es oben steht, kann die Methode immer noch Exceptions werfen, da kein Default berücksichtigt ist.
 

Zurück
Oben