Try und Catch

[Moch]

Hallo,
Ich habe nochmal eine kurze Frage zum try & catch bei Java, das sich mir jetzt nicht zur Gänze erschließt.

Mir ist bewusst, dass dieses Konstrukt dazu da ist, eine Exception aufzufangen, sollte diese beim "Versuch" auftreten, um dann ggf. automatische Gegenmaßnahmen (wie erneute Eingabe) zu vernanlassen oder aber das Programm zumindest nicht sofort zu beenden.

Meine Frage jetzt: Offenbar werden alle auftretenden Exceptions aufgefangen?!?! Kann ich das irgendwie verhindern oder zumindest dafür sorgen, dass besagte ExceptionSignatur mit ausgegeben wird, damit ich mir ein Bild von der Lage machen kann, was da schief läuft.




Folgendes Problem trat auf: Ich arbeite momentan aus Spaß an einem SudokuLöserProgramm.
An einer Stelle sollte der User eine Zahl eingeben können. Für den Fall, dass der User nun nen Torfkopp ist oder sich vertippt, habe ich das umwandeln in einen Integer mit try und catch versehen und lasse das Programm die Eingabe des Users ingorieren und eine kurze Erklärung ausgeben.
Nun wurde mir jedes Mal diese Erklärung ausgegeben, obwohl meine Eingabe definitiv korrekt war.
Das Problem war schnell gefunden: Ich hatte einen Programmierfehler in der aufgerufenen Methode eingebaut, der eine OutOfBoundsException werfen musste. Offenbar wurde besagter Fehler leider abgefangen, sodass es für mich schwierig wurde, ihn zu lokalisieren.

Es ist ja schön und gut mit einem Fehler des Anwender zu rechnen, aber meine eigenen Fehler möchte ich ungerne mit auffangen, da es hier im schlimmsten Falle dazu führen kann, dass ich einen Fehler nicht bemerke, dass Programm locker flockig drüberwegbügelt und später totalen nonsense ausgibt.

liebe Grüße
Moch

 

[Marco13]

Immer die spezifischste Exception fangen. In diesem fall

catch (NumberFormatException e) {
    System.out.println("Falsche Eingabe");
}

Normalerweise NIE sowas wie [c]catch(Exception e)[/c] (es gibt Fälle, wo man das macht, aber wer nicht weiß, wo und warum, sollte es nicht machen 😉 )

 

[Moch]

Ahh, vielen Dank! Ich hatte offenbar einen völligen Verständnisfehler drinne...

Ich gebe also erst den Exceptiontyp (z.B. OutOfBoundsException) an und danach irgendeinen Namen?


Sorry, wir hatten Exceptions in der Vorlesung nur am Rande :-D ... ich weiß nur, was eine solche ist, wie ich selbst welche erzeuge und werfe (also eigene Exceptions) und wie ich ggf. über Try und Catch sowas abfange (mein Wissen belief sich offenbar darauf, wie ich einfach alles abfangen)

Dann vielleicht nochmal eine kurze Frage dazu: Wenn man Exceptions selbst entwickelt und die dann irgendwo einbaut, muss die ja in allen Methoden, die diese verursachen können bzw. in allen Methoden, die eine solche Methode aufrufen bzw. aufrufen können sozusagen erwähnt werden ([/code]throws IrgendwasException[/code])
Bisher macht mein Eclipse das für mich, indem ich einfach doppelt auf den Fehler klicke und sage: Hier, mach mal!

Ich kann mir vorstellen, dass dadurch bei größeren Projekte mancher Methoden-Kopf (heißts in Java so?) unübersichtlich bis nervig wird. Gibt es hier die Möglichkeit einfach generalisiert irgendwie zu sagen, dass das Ding eine Maße an Exceptions werfen kann oder muss ich definitiv jede einzelne Exception im Kopf angeben?

Liebe Grüße und nochmals vielen Dank 🙂
Moch

 

[despikeexd]

Das geht schon ... nur sollte man es vermeiden eine Super-Klasse von Exceptions anzugeben wenn man sich nicht 100% sicher ist was man damit tut und vor allem WARUM. In der Regel sollte man wirklich jede Exception die geworfen werden kann explizit angeben, wobei aber auch die Reihenfolge entscheident ist.
So würde dir z.B. foldendes IMMER eine IOException liefern ... egal ob nun als IOException selbst oder als Sub-Klasse

public void connect() throws IOException, SocketException

Der Grund liegt darin das SocketException eine Sub-Klasse von IOException ist, wesshalb bei der Typ-Prüfung IOException als gültige Klasse ausgewählt wird.
Genau so ist , wie hier , auch die Reihenfolge in try-catch Blöcken wichtig. Wenn du z.B. IOException VOR SocketException prüfst wirst du immer nur die IOException zu gesicht bekommen.

 

[Moch]

Alles klar, danke! 🙂

Gut, bisher verwende ich eher kaum die vorgegebenen Exceptions, sondern bastle meistens selbst welche, aber das liegt wohl eher an den Programmen, die ich schreibe.
Ich habe jetzt selbst den ersten Fall, in welchem ich eine OutOfBoundsException abfangen muss. Hierbei soll der Anwender das Feld des Sudokus angeben, welches er bearbeiten möchte. Nun könnte er aber auch das Feld 10/9 ansprechen, was eine solche Exceptions produzieren würde.

Aber das mit den Exceptions läuft bei mir jetzt.

Vielen Dank nochmals 🙂

Thema erledigt

 

[Marco13]

Genau so ist , wie hier , auch die Reihenfolge in try-catch Blöcken wichtig. Wenn du z.B. IOException VOR SocketException prüfst wirst du immer nur die IOException zu gesicht bekommen.

In der falschen Reihenfolge sollte sich der Code nicht compilieren lassen.


@Moch: Man sollte mit eigenen Exception-Klassen sehr, sehr sparsam umgehen. In den ALLERmeisten Fällen reichen die, die es schon gibt (oft z.B. eine IllegalArgumentException). Das 'throws SomeException' muss man nur hinschreiben, wenn die jeweilige 'SomeException'-Klasse von 'Exception' erbt. Wenn sie von 'RuntimeException' erbt, muss man es NICHT hinschreiben. Das ist der Unterschied zwischen "checked Exception" und "unchecked Exceptions" (mal eine Websuche danach machen!). Und in den meisten Fällen sollte man, wenn überhaupt, von RuntimeException erben. (Selbst 'große' Projekte verwenden keine "checked Exceptions" mehr).
Und... ganz nebenbei: Manche Exceptions (ArrayIndexOutOfBounds oder NullPointer) sollte man NICHT abfangen. Die deuten nämlich auf einen Programmierfehler hin. Ein eindeutiges Kriterium, welche man abfangen sollte, und welche nicht, kann ich spontan aber nicht nennen.
Man sollte nur aufpassen, dass man Exceptions nicht zur "Steuerung der Programmlogik" verwendet. Exceptions sind, wie der Name schon sagt, eine Ausnahmesituation. Statt sowas wie

void setNumber(int r, int c, int value) {
    try {
        array[r][c] = value;
    } catch (ArrayIndexOutOfBoundsException e) {
        System.out.println("Falsche eingabe");
    } catch (NullPointerException e) {
        System.out.println("Nicht initialisiert");
    }
}

sollte man besser (durch if-Abfragen oder so) vornherein verhindern, dass die Methode mit ungültigen Werten aufgerufen wird. Und wenn sie DOCH mit ungültigen Werten aufgerufen wird, kann auch die AIOOBE fliegen, weil dann ist das ein Zeichen dafür, dass ("ausnahmsweise") ein Fehler aufgetreten ist.