Fragen zu Exceptions

[JavaIsTheBest]

Hallo,
ich beschäftige mich gerade mit Exceptions und hätte dazu ein paar Fragen.

1. Was ist der Unterschied zwischen checked und unchecked Exceptions? Ich weiß, dass unchecked E. alle RuntimeExceptions + Kindklassen sind und cheched E. der Rest.
2. Was ist mit "Exception wird an den Aufrufer weitergeleitet" gemein?Wer ist der Aufrufer?
3. Warum sollte man eine Exception weiterleiten? Welchen Grund hat das?
4. Warum müssen RuntimeException nicht aufgefangen werden
5. Wann benutze ich eine try/catch und wann eine throw Anweisung?
6. Wann kommt die throw Anweisung in den Methodenkopf?

 

[Viktim]

1.) Checked Exceptiones sind die, bei denen du eine warnung kriegst, wenn du kein Try / Catch oder throws hast, wie die IOException
Unchechecked Exceptions sind solche wie eine NullPointerException bei denen kein Try Catch abgefangen wird.

2.) Ich denke mal damit ist das Thorws gemeint. Throws wird ja in die Methodensignatur geschrieben und reicht die Exception einfach an die Stelle weiter, wo die methode aufgerufen wurde.

3.) Weil eine Fehlerbehandlung durch try und catch für viele Methoden manchmal an einer Zentralen stelle sinnfoll ist.

4.) Alle Runtime Exceptions sind unchecked. Und es macht einfach keinen Sinn eine Nullpointer oder ArrayOutOfBounds Exception abfangen zu müssen... Dann wäre ja alles Voll mit Try und Catch

5. ) Siehe 3. Wenn es sinnfoll ist den Fehler sofort an Ort und Stelle zu behandeln dann Try und Catch. Wenn du behandlung in einer Höheren Methode sinnfoller ist, dann Throws.

6.) Wenn du throw benutzen willst

 

[JStein52]

6. Wann kommt die throw Anweisung in den Methodenkopf?

Was verstehst du unter dem Methodenkopf ? Du musst unterscheiden zwischen throw und throws .
Throws steht bei der Methodendeklaration, ist Teil der Signatur einer Methode und zeigt an dass diese Methode die angegebene Exception nicht selber abfängt sondern sie an den Aufrufer weitergibt. throw steht im Anweisungsteil und wirft die angegebene Exception.

 

[Viktim]

Du musst unterscheiden zwischen throw und throws .

Ohh stimmt ja das hab ich total verpeilt

EDIT: Jedes Throw oben muss Throws sein

 

[Saheeda]

Mein Senf:

throws muss in den Methodenkopf, wenn die Exception checked ist, aber von der Methode selbst nicht abgefangen wird.
Bei unchecked Exceptions _muss_ kein throws rein, selbst wenn die Exception händisch in der Methode geworfen wird. Man _kann_ es aber schreiben.

 public static void causesException() throws DataFormatException {
        throw new DataFormatException();
    }

    public static void catchesException() {
        try {

            throw new DataFormatException();

        } catch (DataFormatException e) {
        }

    }

    public static void causesRuntimeExceptionWithoutThrow() {
        throw new RuntimeException();
    }

    public static void causesRuntimeExceptionWithThrow() throws RuntimeException {
        throw new RuntimeException();
    }

 

[JavaIsTheBest]

Diese Stelle verstehe ich noch nicht.

Throws wird ja in die Methodensignatur geschrieben und reicht die Exception einfach an die Stelle weiter, wo die methode aufgerufen wurde.

public void a(){
        public void b(){
            public void a() throws FileNotFoundException{
               
            }
        }
    }

Wohin wird die Exception in dem Beispiel weitergereicht?

Und kennt ihr ein Beispiel, wann es Sinn macht, eine Exception weiterzureichen?

 

[mrBrown]

Diese Stelle verstehe ich noch nicht.

Throws wird ja in die Methodensignatur geschrieben und reicht die Exception einfach an die Stelle weiter, wo die methode aufgerufen wurde.

public void a(){
        public void b(){
            public void a() throws FileNotFoundException{
             
            }
        }
    }

Wohin wird die Exception in dem Beispiel weitergereicht?

Kein valider JavaCode, deshalb ein recht schlechtes Beispiel
Wenn b a aufruft, und a eine Exception wird, kann b entscheiden, ob sie catcht, oder wirft. Wenn sie wirft, kann die b aufrufenden Methode dies wieder genauso entscheiden.

Und kennt ihr ein Beispiel, wann es Sinn macht, eine Exception weiterzureichen?

In den meisten Fällen

Selten macht es Sinn, den Fehler da zu behandeln wo er auftritt. ZB soll ja oftmals eine Fehlermeldung dem User angezeigt werden, wenn das dann schon ganz unten abgefangen werden würde, würden die Klassen, die dem Nutzer

 

[JavaIsTheBest]

Wenn b a aufruft, und a eine Exception wird, kann b entscheiden, ob sie catcht, oder wirft. Wenn sie wirft, kann die b aufrufenden Methode dies wieder genauso entscheiden.

Meinst du a ?

Ich glaube, der letzte Satz ist nicht ganz vollständig?

 

[mrBrown]

c ruft b ruft a auf.

schmeißt a, kann b fangen oder schmeißen, schmeißt b, kann c fangen oder schmeißen, usw

 

[JavaIsTheBest]

Sorry, dass ich soviel frage

Falls a, schmeißt. Muss die Methode b, dann so implementiert werden, dass es in b, entweder ein try/catch Block gibt oder ein throws oder kann ich sogar beide (try/catch und throws) weglassen?

Und warum macht es selten Sinn, den Fehler, da abzufangen, wo er auftritt?
Falls der User einen String anstatt einer Zahl eingibt, dann würde ich persönlich den User gleich darauf aufmerksam machen und den Fehler nicht einfach ignorieren.

 

[mrBrown]

Sorry, dass ich soviel frage

Falls a, schmeißt. Muss die Methode b, dann so implementiert werden, dass es in b, entweder ein try/catch Block gibt oder ein throws oder kann ich sogar beide (try/catch und throws) weglassen?

Wenn es eine checked Exception ist, muss eines von beiden gemacht werden

Und warum macht es selten Sinn, den Fehler, da abzufangen, wo er auftritt?
Falls der User einen String anstatt einer Zahl eingibt, dann würde ich persönlich den User gleich darauf aufmerksam machen und den Fehler nicht einfach ignorieren.

Ja, aber die Funktion, die dann zB beim Umwandeln einen Exception werfen würde, kann den User nicht drauf aufmerksam machen. Das muss eine in der Logik weiter oben stehende Klasse ("näher beim User") machen

 

[JavaIsTheBest]

Ja, aber die Funktion, die dann zB beim Umwandeln einen Exception werfen würde, kann den User nicht drauf aufmerksam machen. Das muss eine in der Logik weiter oben stehende Klasse ("näher beim User") machen

Doch, wenn ich die Exception da werfe, wo der Fehler auftritt, dann könnte ich doch, in der Konsole eine Meldung ausgeben (Z.B.: "Falsche Eingabe!!!"). So, wird der User drauf aufmerksam gemacht.

 

[mrBrown]

Doch, wenn ich die Exception da werfe, wo der Fehler auftritt, dann könnte ich doch, in der Konsole eine Meldung ausgeben (Z.B.: "Falsche Eingabe!!!"). So, wird der User drauf aufmerksam gemacht.

Dazu muss deine Klasse, die den String in eine Zahl umwandelt, die Klassen kennen, die mit dem Nutzer interagieren
In deinem Programm oben einfach die Konsole gegen ein Fenster tauschen geht nicht - außer du passt deine Umwandlungsklasse dann auch an, was dann Designfehler wäre

 

[Saheeda]

@JavaIsTheBest

Mal ein Beispiel aus einem aktuellen Projekt:
In der Oberfläche gibt es ein Menü, um Exceldateien hochzuladen und deren Daten importieren zu können.

Der Controller sieht vereinfacht gesagt so aus:

public void ActionResponse(byte[] file){
        ImportService service = new ImportService();
   
       
try{
            service.doImport(file);
            return new ActionResponse("import successfull");
        } catch(ExcelImportException e){
            return new ActionResponse("error while importing " + e.getMessage());           
        } catch(DatabaseConnectionException e){
            return new ActionResponse("database lost during import " + e.getMessage());           
        } 
    }

Der eigentliche Import findet im Service statt und geht dort durch mehrere Methode/Klassen: Die Datei muss erstmal ausgelesen und später interpretiert/in die Datenbank geschrieben werden.
Unterwegs gibts gefühlt ne Million potentielle Fehlerquellen. Die alle an Ort und Stelle zu behandeln wäre nicht sinnvoll, da ich sonst im Controller keine Möglichkeit mehr habe, den User zu informieren, ob der Import erfolgreich war oder nicht. Einen boolean durchzuschleifen, der sagt, ob das ganze erfolgreich, ist nicht schön, da dir irgendwann der Grund verloren geht. Warum passierte ein Fehler? Und bei welchem Eintrag der Exceldatei? Und ist das n Benutzerfehler oder ist z.B. die Datenbankverbindung zwischendrin weggebrochen? N String mit ner Message durchzuschleifen ist auch Mist, die Rückgabetypen brauche ich meistens für was anderes als eine eventuell benötigte Fehlermeldung.
Plus: Über verschiedene Exceptions kann ich im Controller gezielter reagieren und verschiedene Fehlermeldungen rausgeben.

Also werfe ich im Service verschiedene Exception bzw. fange Java-Eigene ab und wandle sie so um, wie ich sie auswerten kann, ungefähr so:

private void saveItems(Set<User> users){
   
        for(User u : users){       
            try{
                this.database.save(u);
            } catch(ConstraintViolationException e){
                throw new ExcelImportExcelption ("was not able to save user with login " + u.getLogin()  + " " + e.getMessage());
            }
        }
    }

Das Ganze ist wesentlich umfangreicher, aber das würde hier glaube ich zu weit führen.

 

[JavaIsTheBest]

Ich habe es leider immer noch nicht verstanden, warum man Exceptions nicht an Ort und Stelle behandelt

 

[Saheeda]

Weil es nicht immer sinnvoll ist. Wenn ich bei meinem Import beispielsweise einen Datensatz nicht speichern kann (fehlerhaft, unvollständig), kann ich zu dem Zeitpunkt nicht entscheiden, was damit passieren soll. Also gebe ich den Fehler zurück an den Controller, der dann eine für den Nutzer verständliche Meldung draus macht.

Alternative wäre, den Datensatz unter den Tisch fallen zu lassen (Nutzer denkt, es wäre alles ok, was aber nicht stimmt) oder mit Dummy-Daten zu ergänzen. Letzteres ist auch nur begrenzt möglich und ziemlich dreckig.

 

[Joose]

Ich habe es leider immer noch nicht verstanden, warum man Exceptions nicht an Ort und Stelle behandelt

Folgende Methode sei gegeben:

public int convertToInt(String number) {
    int result = 0;
    try {
        result = Integer.parseInt(number);
    } catch(NumberFormatException nfex) {
        // exception behandeln?
    }
    return result;
}

Die Methode Integer.parseInt kann eine NumberFormatException werfen. Diese kannst du ohne weiteres auffangen, nur wie schaut in diesem Fall deine Fehlerbehandlung aus?
Es ist einfach nicht möglich an dieser Stelle eine sinnvolle und nachvollziehbare Fehlerbehandlung zu schreiben! Daher sollte die Exception nicht direkt hier behandelt werden sondern einfach weitergeworfen werden.

Auch kannst du in dieser Methode nicht wissen woher der Parameter kommt: War es eine Usereingabe? Wurde der Wert aus einer Datei gelesen? Daher kann man auch schlecht nach einen neuen Wert fragen.

 

[JavaIsTheBest]

@Joose, das war schon verständlicher für mich.
Nur, warum macht es keinen Sinn an dieser Stelle eine System.Out.println("Falsche Eingabe"); Meldung auszugeben?
Dann würde der User darauf aufmerksam gemacht.

 

[mrBrown]

@Joose, das war schon verständlicher für mich.
Nur, warum macht es keinen Sinn an dieser Stelle eine System.Out.println("Falsche Eingabe"); Meldung auszugeben?
Dann würde der User darauf aufmerksam gemacht.

Vllt wird die Methode in einem Webserver verwendet, da sieht uU niemand die Konsole, der Ausgabe ist also verloren.
Außerdem muss die Methode trotzdem was zurückgeben, und die aufrufende Methode weiß dann nicht, ob das der umgewandelte Wert war, oder ein Fehler auftrat.

 

[JavaIsTheBest]

Ok, und wie lange muss die Exception geworfen werden?
Wann macht es Sinn den Fehler, mit einem try/catch Konstrukt zu beheben? In der main Methode?

 

[Joose]

Nur, warum macht es keinen Sinn an dieser Stelle eine System.Out.println("Falsche Eingabe"); Meldung auszugeben?
Dann würde der User darauf aufmerksam gemacht.

Es gibt viele Programme die laufen auf einen Server ohne User der davor sitzt, hier wäre es fatal plötzlich ein Fenster aufpoppen zu lassen mit einer Fehlermeldung.
Hingegen ist bei einem Programm mit GUI selten die Konsole offen, sprich so eine Konsolenausgabe würde verloren gehen.

Natürlich kannst du so eine Ausgabe einbauen, diese würde dann aber eher unter "Logging" fallen. Das ist noch lange nicht eine Fehlerbehandlung.

Wann macht es Sinn den Fehler, mit einem try/catch Konstrukt zu beheben? In der main Methode?

Das kommt ganz darauf an um welche Exception es sich handelt und ob man sie beheben kann bzw. wo es eben sinnvoll ist.

 

[stg]

Dann will ich auch noch mal meinen Senf dazu geben, um noch ein bisschen mehr Verwirrung zu stiften:

Oft ist es nicht sinnvoll eine Exception einfach an den Aufrufer durchzureichen, sondern die Exception sollte gefangen werden, und anschließend eine Layer-spezifische Exception geworfen und an die aufrufende Methode weitergereicht werden. Andernfalls werden Implementierungs-Details über mehrere Schichten preisgegeben, was selbst schon bei relativ kleinen Anwendungen zu Problemen führen kann.

Das Ganze wird zum Beispiel hier näher erläutert:
http://www.programmr.com/blogs/what...know-about-wrapping-and-rethrowing-exceptions

 

[JavaIsTheBest]

Ok, mir ist jetzt klar, dass es Sinn macht, eine Exception zu werfen, aber ich weiß immer noch nicht, wann es Sinn macht, eine geworfene Exception zu fangen.

 

[Joose]

...... aber ich weiß immer noch nicht, wann es Sinn macht, eine geworfene Exception zu fangen.

Das kommt ganz auf den Kontext an, man kann hier keine fixe Regeln vorgeben.

Man behandelt/fängt eine Exception dort wo es Sinn macht und man die Exception auch wirklich behandeln kann.

 

[stg]

Dann, wenn du sie sinnvoll behandeln kannst. Oft ist es erst der User, der vor der UI sitzt, der entscheiden kann/soll, was bei einem Fehler passiert.
Auf eine konkrete Antwort wirst du leider vergeblich warten, da die Frage zu allgemein gefasst ist.