Verständnisproblem: Exceptions

[ghoztdog]

Hallo Leute!

Obwohl ich mich mit Java schon eine Weile beschäftige, ist mir der Sinn (oder Unsinn?!) von Exceptions immer noch nicht klar geworden. Das hat inzwischen dazu geführt, dass ich ich sie fast komplett ignoriere....aber das kann ja irgendwie auch nicht Sinn der Sache sein! :bahnhof:

Wenn man sich hier im Forum oder allgemein im Netz informiert, werden einem die unterschiedlichsten Sichweisen aufgezeigt. Verstanden habe ich bisher nur, das in Exceptions keine "Programmlogik" ausgeführt werden soll, ist das so richtig? Aber wozu dann das ganze? Wenn ich nur nen Stack-Trace ausgebe, hilft mir das doch nur den Fehler zu lokalisieren. Könnte das nicht ganz einfach automatisch von der vm erstellt werden, statt den Code dem "Try-Catch"-Blöcken "unleserlich" zu gestalten?

Also ich hoffe es ist verständlich wo mein Problem liegt. Links zu Büchern helfen mir nicht, weil dort die Frage nach dem Sinn auch nicht richtig geklärt wird. Ich steh einfach auf dem Schlauch, vielleicht hat jemand eine narrensichere Erklärung oder ein Beispiel?

Vielen Dank

 

[Gast2]

Es gibt Exceptions die einen Fehler in deinem Programm repräsentieren, z.b. ne Nullpointerexception. Die sollte in deinem Programm nie auftreten. Wenn doch dann kannst du anhand des Stacktraces sehen wo der Fehler lag und den beheben.
Es gibt aber auch Fehler die durchaus auftreten können in deinem Programm. Nehmen wir mal an du willst ne Datei einlesen:
Wenn die Datei nicht existiert dann fliegt dir eine IOException um die Ohren. Diese kannst du in deinem Programm fangen (try-catch) und entsprechend drauf reagieren, z.b. kannst du die Datei neu anlegen.
Danach kann dein Programm dann normal weiterarbeiten.

 

[gman]

Wenn ich nur nen Stack-Trace ausgebe, hilft mir das doch nur den Fehler zu lokalisieren.

Was die Sache ganz erheblich erleichtert wenn man mal an einem etwas größerem und komplexerem Programm
arbeitet.

 

[XHelp]

Du siehst echt auf anhieb nicht, wo der Vorteil ist, wenn du über Programmfehler informiert wirst? Hm...
Und in Exceptions wird überhaupt nichts ausgeführt...
Du fängst den Fehler nicht nur um StackTrace auszugeben, sondern um Fehlerbehandlung durchzuführen. Was da genau passieren soll hängt natürlich davon ab was du überhaupt brauchst.

 

[ghoztdog]

Du siehst echt auf anhieb nicht, wo der Vorteil ist, wenn du über Programmfehler informiert wirst? Hm...
Und in Exceptions wird überhaupt nichts ausgeführt...
Du fängst den Fehler nicht nur um StackTrace auszugeben, sondern um Fehlerbehandlung durchzuführen. Was da genau passieren soll hängt natürlich davon ab was du überhaupt brauchst.

Doch, natürlich sehe ich den Vorteil wenn ich über einen Programmfehler informiert werde! Ich verstehe nur nicht warum ich explizit angeben muss, darüber informiert zu werden? Sollte so etwas nicht automatisch geschehen?
Ja, und du hast recht, in der Exception wird natürlich nichts ausgeführt, ich habe mich da wohl etwas ungünstig ausgedrückt. Mir gehts wohl wirklich um die Fehlerbehandlung.

Das Beispeil von EikeB macht schon Sinn, aber andere Beispiele fallen mir nicht mehr ein.
Angenommen ich mochte eine einfach Methode verweden, die eine Parameterüberprüfung durchführen soll und ein Ergebnis zurückliefert. Jetzt stellt sich herraus (aus welchen Gründen auch immer), das eine Null-Referent übergeben wird. Aber die Methode muss ja einen Wert zurückgeben? Ist dann der Catch-Block dafür geeignet einen erlaubten Wert zu definieren und zurückzugeben?

 

[Marcinek]

Der eigentliche Sinn und Vorteil einer Exception ist, wie der Name schon sagt, eine Außnahme bekannt zu machen.

Wenn du eine Methode hast, die ein Wert berechnen soll, jedoch aufgrund falscher Vorbedingungen nicht möglich ist, dann hast du 2 Möglichkeiten.

1. Eine Exception
2. Einen Wert, der vom typ X ist, zurück geben, der aber gleichzeitig einen Fehler andeutet.

In beiden Fällen musst du auf den Fehler reagieren, jedoch ist durch eine Exception schon bei der Implementierung möglich zu sagen, welche Fehler an dieser Stelle möglich sind.

~~ Nachtrag, weil TO gleichzeitig gepostet hat:

Automatisch kann da nix passieren, was die Fehlerbehandlung angeht.

Wie du schon selber sagst, kann der Fehler abgefangen und ein gültiger Rückgabewert generiert werden um den Programmablauf nicht zu stören.

Manchmal kann man sich aber von einer Exception nicht "erhholen". Und darüber müssen dann nacheinander im Stack sich befindliche Aufrufer iinformeirt werden. Einer wird sich schon für die Verarbeitung der Exception zuständig fühlen.

Das geht übrigens auch nicht indem man immer einen fehlerwert übergibt ...

 

[Gast2]

Angenommen ich mochte eine einfach Methode verweden, die eine Parameterüberprüfung durchführen soll und ein Ergebnis zurückliefert. Jetzt stellt sich herraus (aus welchen Gründen auch immer), das eine Null-Referent übergeben wird. Aber die Methode muss ja einen Wert zurückgeben? Ist dann der Catch-Block dafür geeignet einen erlaubten Wert zu definieren und zurückzugeben?

WAHHH, Nein!
Der catch-Block dient nur zur Fehlerbehandlung. Das was du beschreibst würde deinen Programmablauf steuern. Das sollte man nie mischen.
In dem Beispiel würde die Methode wohl eine IllegalArgumentException werfen, also so nach dem Motto:

if (param == null) {
   throw new IllegalArgumentException("param darf nicht null sein");
}

Ich verstehe nur nicht warum ich explizit angeben muss, darüber informiert zu werden? Sollte so etwas nicht automatisch geschehen?

Es gibt Exceptions die du nicht explizit per try-catch fangen musst (RuntimeException). Wenn diese auftreten wird dein Programm beendet und du bekommst den Stacktrace.

 

[ghoztdog]

Also erstmal vielen Dank für die schnelle Hilfe an alle!
Ich glaube so langsam kommt Licht ins Dunkle!

Ich will mal kurz kurz klarstellen ob ich das jetzt verstande habe:

-Der Catch-Block soll den Programmablauf nicht steuern, sondern ausschließlich die Methode selbst.

-Der Catch-Block soll mir jediglich mitteilen, das ein Fehler aufgetreten ist, evtl. wo er aufgetreten ist, und bestenfalls noch den Anwender darüber informieren ("Datei nicht gefunden...").

?

 

[Gast2]

-Der Catch-Block soll mir jediglich mitteilen, das ein Fehler aufgetreten ist, evtl. wo er aufgetreten ist, und bestenfalls noch den Anwender darüber informieren ("Datei nicht gefunden...")..

Nicht ganz.
Der catch block kann, muss aber nicht, dem Programm die Möglihckeit geben einen Fehler zu beheben. Z.b. eine Falscheingabe des Users (er soll ne zahl eingeben, gibt aber "abc" ein), oder wie vorher beschrieben ne IOException beheben.
Falls dann wirklich alle stricke reißen sollte man die Exception loggen oder dem user anderweitig mitteilen.

 

[ghoztdog]

Nicht ganz.
Der catch block kann, muss aber nicht, dem Programm die Möglihckeit geben einen Fehler zu beheben. Z.b. eine Falscheingabe des Users (er soll ne zahl eingeben, gibt aber "abc" ein) ... .

So...und genau das ist mein Problem!
Wie soll denn so ein Fehler behoben werden? Ich müsste den Wert also verwerfen, ihn umwandeln (macht keinen Sinn) oder wie von Marcinek beschrieben einen Wert zurückgeben der gleichzeitig auf einen Fehler hindeutet. Und wo mach ich das? Doch wieder im Catch-Block...aber gerade das soll ich doch nicht tun?!

Es tut mir leid, ich glaube ich stell mich wirklich etwas "unbeholfen" bei dem Thema an, aber ich muss das jetzt endlich mal verstehen....

 

[Marcinek]

Nein.. Ich glaube ich habe mich bisschen falsch ausgedrückt.


Im Catch Block kannst du versuchen einen Fehler zu beheben.... Wenn eine Zahl kommen soll beispiel 30 und es kommt aber 30c (warum auch immer) dann kannst du entweder einen default wert annehmen oder versuchen den String zu bereinigen, oder du wirfst die exception weiter...

Der Aufrufer muss entscheiden, was damit passieren soll... Wenn der auch nix machen kann, dann wirft er sie weiter... iwann bist du iwo angekommen, wo das werfen nicht mehr weiter geht.. Dann spätestens musst du was machen oder du bist in main() angekommen, da kannst du auch werfen, dann bricht allerdings das Programm ab mit einer unhandelt exception fehlermeldung.

Das ist auch noch unvollständig erklärt. Ich denke, wenn du ein Programm machst mit mehr als 2 Klassen, dann wird das auch noch deutlicher.

Auf keinen Fall kannst du das verallgemeinern. Das ist nur einer von unendlich möglichkeiten, wie es laufen kann...

 

[Ark]

Nach meinen Erfahrungen kommt try-catch vergleichsweise selten vor, nämlich nur da, wo man einen Fehler auch behandeln kann.

Beispiel: Du hast eine reine Kommandozeilenschnittstelle, sprich: keine Nutzerinteraktion, sondern alles, was das Programm wissen muss, kommt über die Argumente der main()-Methode rein. Dein Programm soll z.B. alle Dateien in einem Verzeichnis auf eine bestimmte Art und Weise verarbeiten.

Nun kann es vorkommen, dass dein Programm bei einigen Dateien weiß: "Ich muss jetzt dieunddie Informationen extrahieren und in dieunddie Datei schreiben." Welche Datei genau es ist, wo die Informationen hingehen sollen, ist je nach Eingabedatei verschieden.

Nun kann es sein, dass einige dieser Ausgabedateien nicht erstellt werden können, weil z.B. das Zielverzeichnis nicht beschreibbar ist. Wie geht man damit um? Hier mal Pseudocode:

// Pseudocode
main(eingabe[], wasTunImFehlerfall){
	for(Eingabedatei d:eingabe){
		verarbeite(d);
	}
}

verarbeite(datei){
	machDiverseUnkritischeOperationen(datei);
	if(mussInfosExtrahieren(datei)){
		extrahiereInfos(datei);
	}
}

extrahiereInfos(datei){
	kritischeOperationen(datei);
}

kritischeOperationen(datei){
	if(gehtSchief(datei)) throw new Ausnahme();
}

Frage: Wo muss jetzt ein try-catch rum, wo muss throws stehen? Faustregel: Wenn eine Methode nicht wirklich alle notwendigen Informationen hat, um die Ausnahme zu behandeln, dann kann sie sie nicht behandeln (-> throws). Wenn die Methode aber Anweisungen bekommen hat (sei es direkt über Parameter oder indirekt, z.B. über eine Konfigurationsdatei, oder implizit, weil sie per definitionem keine Ausnahme werfen darf), was sie im Fehlerfall tun soll, dann ist ein try-catch in dieser Methode notwendig.

In diesem Fall muss throws zu [c]kritischeOperationen()[/c], [c]extrahiereInfos()[/c] und [c]verarbeite()[/c]. Grund: Diese Methoden wissen gar nicht, was sie jetzt tun sollen. Eine Fehlermeldung ausgeben? Gar nichts tun und Fehler ignorieren? Eine Melodie abspielen? Bildschirm blau färben? Rechner runterfahren? Tja, das ist da einfach noch nicht bekannt.

Erst in [c]main()[/c] ist (hier explizit über den Parameter [c]wasTunImFehlerfall[/c]) auch klar, was überhaupt passieren soll, wenn etwas nicht funktioniert. Und das sieht dann z.B. so aus:

// Pseudocode
main(eingabe[], wasTunImFehlerfall){
	for(Eingabedatei d:eingabe){
		try{
			verarbeite(d);
		}
		catch(ausnahme){
			if(wasTunImFehlerfall==ignorieren){
				continue;
			}
			if(wasTunImFehlerfall==pseudoinfosSchreiben){
				schreibePseudoinfos(d);
				continue;
			}
			if(wasTunImFehlerfall==meldenUndFortfahren){
				System.err.println("Fehler beim Verarbeiten von "+d+": "+ausnahme.getMessage());
				continue;
			}
			if(wasTunImFehlerfall==meldenUndAbbrechen){
				System.err.println("Fehler beim Verarbeiten von "+d+": "+ausnahme.getMessage());
				System.err.println("Abbruch.");
				break;
			}
		}
	}
}

verarbeite(datei) throws Ausnahme{
	machDiverseUnkritischeOperationen(datei);
	if(mussInfosExtrahieren(datei)){
		extrahiereInfos(datei);
	}
}

extrahiereInfos(datei) throws Ausnahme{
	kritischeOperationen(datei);
}

kritischeOperationen(datei) throws Ausnahme{
	if(gehtSchief(datei)) throw new Ausnahme();
}

Ist das jetzt klarer?

Wichtig: Wenn Rückgabewerte im Spiel sind, und die Methode damit droht, aufgrund einer Ausnahme einen falschen Wert zurückzugeben (also einen Wert, der laut Schnittstellenbeschreibung wie ein richtiger Wert aussieht, aber aufgrund der Ausnahme garantiert falsch ist), dann muss sie eine Ausnahme werfen!

Ark

PS: Der Pseudocode ist nicht gerade der schönste. Auch wenn switch-case sinnvoller und weniger continue nötig ist: Es geht hier nicht um schönen Code, sondern um besseres Verständnis.

 

[ghoztdog]

Nein.. Ich glaube ich habe mich bisschen falsch ausgedrückt.


Im Catch Block kannst du versuchen einen Fehler zu beheben.... Wenn eine Zahl kommen soll beispiel 30 und es kommt aber 30c (warum auch immer) dann kannst du entweder einen default wert annehmen oder versuchen den String zu bereinigen, oder ...

also wäre das hier in Ordnung und im Sinne einer Ausnahmebehandlung(?):

public int add(String a, String b) {
        int result;
        try {
            result = Integer.parseInt( a ) + Integer.parseInt( b );
        }
        catch (NumberFormatException ex ) {
            result = 0;
        }
        return result;
    }

 

[Gast2]

Ich würde sowas machen:

public int add(String a, String b) throws NumberFormatException {
        int result = Integer.parseInt( a ) + Integer.parseInt( b );
        return result;
}

Dann darf sich der aufrufende Teil darum kümmern wie weitergemacht werden soll.
Aber das hängt natürlich immer von der jeweiligen situation ab.

EDIT:
Du kannst ja nicht einfach davon ausgehen dass der Aufrufer bei fehleingabe 0 als Ergebnis haben will.

 

[Marcinek]

Ja sowas stelle ich mir vor.

Außerdem das, was ElkeB schon gesagt hat.

Es muss also schon überlegt sein..

In diesem speziellen Fall würde ich sagen, dass der Aufrufer (Nur er weiß, wie man die Zahlen korrigieren kann) diese Exception handelt.

 

[ghoztdog]

Nach meinen Erfahrungen kommt try-catch vergleichsweise selten vor, nämlich nur da, wo man einen Fehler auch behandeln kann.

...

Ist das jetzt klarer?

Ja!!! Danke für das ausführliche Beispiel. Ich denke mal EikeB wollte mit dem letzten Post ebenfalls darauf hinweisen. Über das Weiterleiten des Fehlers hatte ich noch gar nicht nachgedacht^^ Aber jetzt macht es schon etwas mehr Sinn...

Wichtig: Wenn Rückgabewerte im Spiel sind, und die Methode damit droht, aufgrund einer Ausnahme einen falschen Wert zurückzugeben (also einen Wert, der laut Schnittstellenbeschreibung wie ein richtiger Wert aussieht, aber aufgrund der Ausnahme garantiert falsch ist), dann muss sie eine Ausnahme werfen!

Das klingt nach einer guten Regel! Ich werde mal versuchen das so umzusetzten...

 

[slawaweis]

Obwohl ich mich mit Java schon eine Weile beschäftige, ist mir der Sinn (oder Unsinn?!) von Exceptions immer noch nicht klar geworden. Das hat inzwischen dazu geführt, dass ich ich sie fast komplett ignoriere....aber das kann ja irgendwie auch nicht Sinn der Sache sein! :bahnhof:

stell Dir vor es ist ein Fußballspiel. Die Mannschaften spielen, die Fans unterstützen diese und dann läuft ein Nackter über das Fußballfeld. Ist es normal, gehört es zum Spiel? Nein. Wird es eingeplant? Ja, die Sicherheitskräfte laufen hinterher. Exceptions sind "Ausnahmen", die rein theoretisch nicht auftreten dürfen/können, aber durch praktische Faktoren trotzdem auftreten. In einem theoretischen Algorithmus kann man eine beliebig große Datei schreiben, in der Praxis setzt das Dateisystem oder die Festplatte dem klare Grenzen. In der Theorie wird an einen Algorithmus eine Zahl zwischen 1 und 31 übergeben (z.B. ein bestimmter Tag im Monat), in der Praxis kann durch Fehler alles mögliche übergeben werden auch 62, was im theoretischem Algorithmus gar nicht definiert ist.

Früher hat man solche Fehler über Rückgabewerte der Funktionen behandelt. Doch damit gab es viele Probleme, z.B. bei rekursiven Funktionen oder Iterationen. Weiterhin musste man die Abarbeitung irgendwie abbrechen, wenn ein kritischer Fehler auftrat. Um die Programmierung zu vereinfachen und Ausnahmen wirklich Ausnahmen sein lassen, wurden die Exceptions eingeführt.

Das größte Problem in Java mit den Exceptions ist, dass die meisten diese nicht richtig verstehen/verwenden. Eine Basisregel ist, wenn man an einer Stelle nicht weis, was man im Catch-Block machen muss, diese Exception einfach über throws nach Oben leiten. Exceptions sollten, wenn möglich, auf einer höheren Ebene behandelt werden. Wird z.B. ein komplizierter Algorithmus ausgeführt, wobei irgendwo eine Exception auftritt, ist es oft sinnvoller die Änderungen des ganzen Algorithmus rückgängig zu machen und von Vorne zu starten. Dazu sollte man die Exception nicht lokal behandelt, sondern nach Oben weiterreichen.

Eine andere Strategie ist ein ExceptionManager. Anstatt was im Catch-Block zu machen, wird jede Ausnahme mit ihrem Ursprung an einen globalen ExceptionManager weitergeleitet, welcher den globalen Überblick hat und entscheidet, was passiert oder wie diese Ausnahme behandelt wird.

Man sollte die Exception-Behandlung an einigen zentralen Stellen bündeln und diese nicht in kleinen Happen über den ganzen Quelltext verteilen. So sollte man öfters mit "throws" in der Funktionsdeklaration, als mit try-catch arbeiten. Weiterhin sollte man sich sowieso eine globale Exception-Strategie überlegen, wie man trotz Ausnahmen das Programm wieder zum laufen bringt oder dem Anwender eine gut verständliche Nachricht liefert.

Slawa

 

[timbeau]

Ein weiteres großes Feld ist die Verbindung zu externen Ressourcen. Oben wurde schon die Datei angesprochen, es kann auch eine Datenbank sein, eine Webseite, ein bestimmter Port etc pp.

Anstatt das Programm auflaufen zu lassen kann man Infos an den Benutzer weiterleiten wie "Server antwortet nicht", "Aufbau zur Datenbank XYZ nicht möglich" usw.