eigene Exception Klasse

[traps12]

hallo leute!

ich hätte da ne frage zu exception. wenn ich eine eigene Exception Klasse schreibe (also von der Basisklasse Exception ableite), diese aber in der main abfangen will, dann brauche ich doch keine throw klausel werfen oder?

gruß

traps12

 

[remy]

Hi,

damit eine Exception überhaupt Sinn macht, muss sie schon an einer Stelle "geworfen" werden.

Main-Methoden sollten nie ein "throws Exc" enthalten, sondern tatsächlich spätestens dort mit try/catch abgefangen werden.

 

[traps12]

danke für die antwort. aber ist das nicht ein widerspruch, wie kann ich an einer stelle eine throw ex werfen , wenn die main keine throw erhalten darf?

 

[Volvagia]

Ne. An irgend eine Stelle musst du ja abfangen. Wenn die Main throwt, wird das von der VM abgefangen. Sonst wird die Exception immer weiter geleitet, bis irgendwann der Rechner neu startet. (Wird glaub ich Triple Fault genannt.)
Die Main sollte aber nicht throwen, nur Untermethoden. Meiner Meinung nach macht throwen in den wenigsten Fällen wirklich Sinn, da du auf die Exception ja auch reagieren solltest. Wenn du nur eine "Irgend eine Ausnahme ist irgendwo im Programm aufgetreten"-Nachricht in der Main ausgibst, kennt sich weder der Anwender noch du, wenn er dir das mitteilt aus.

 

[traps12]

achso, gut danke.

wenn throwen deiner meinung nach nicht wirklich sinn macht, was sollte man ansonsten machen?
wenn ich z.b duch 0 teilen würde oder anstelle einer zahl ein buchstaben übergebe, kann ich diese vorgänge ja verhindern, aber was meinst du sonst?

 

[Volvagia]

Mit einen try/catch(/finally) umgeben und darauf reagieren.
Wenn du z. B. eine IOException eines Writers/OutputStream weiterleitet, der ausgibt, dass die Datei derzeit von einen anderen Programm gelockt ist, und du diese über die Main throwst, wird die Nachricht in der Shell landen. Aber 99 % der Programme werden ohne sie gestartet (javaw), wodurch der Anwender den Fehler garnicht zu Gesicht bekommt.
Wenn du sie weiter zur Main leitest, kannst du dort nur eine allgemeine Nachricht ausgeben, die alle Ausnamen betrifft, oder du kannst durchgehen, um welche es sich handelt, woran du vermutlich sehr lange sitzten würdest.
Wenn du sie direkt handlest, kannst du soetwas wie "Schreibevorgang fehlgeschlagen.\n\nProgramm meldet\ne.getMessage()" ausgeben lassen, womit man schon sehr viel mehr anfangen, und was vermutlich auch der Anwender verstehen würde.

Ich denke, throwen bringt nur etwas, wenn man Klassen schreibt, die man öfters in Programmen für bestimmte Aufgaben verwendet (so wie die aus der JRE), und nicht, wenn man wie meistens einfache Abläufe schreibt, in denen die anderen Klassen dann verwendet werden.

 

[traps12]

hmm, stimmt.

eine letzte frage noch. du sagtest ja finally block. ánweisungen in diesem block werden aufjedenfall augeführt -exception oder keine exception-

was wäre am sinnvollsten, in so einem finally block zu implementieren?

danke

gruß
traps12

 

[remy]

Oder mit einem Beispiel ausgedrückt, das für ein throws spricht: du hast eine Methode, die bei einer Exception nicht weiter ausgeführt werden soll und diese die Exc an die aufrufende Stelle weitergibt, so dass z.B. eine andere Methode aufgerufen werden soll.
Kannst du aber in der Methode in allen Fällen so reagieren, dass die Methode funktionell und logisch weiter ausgeführt werden kann, ist ein try/catch eher angebracht.

hmm, stimmt.

eine letzte frage noch. du sagtest ja finally block. ánweisungen in diesem block werden aufjedenfall augeführt -exception oder keine exception-

was wäre am sinnvollsten, in so einem finally block zu implementieren?

danke

gruß
traps12

Bekannte Fälle dafür sind Streams und Connections.
Z.B. sollte bei ein FileStream immer versucht werden, diesen wieder zu schließen, um z.B. die Datei wieder freizugeben. Bei Connections, z.B. zu einer Datenbank, sollte auch hier versucht werden, diese zu schließen, um die Ressourcen der Datenbank wieder freizugeben; springt das Programm aus dem try/catch-Block raus, ohne die Connection zu schließen (z.B. bei einem falschen SQL-Statement), bleibt sie offen und die DB wartet bis zum Timeout auf weitere Anweisungen.
Etwas irritierend ist dabei, dass in den Fällen vom Aufruf "close()" von Streams und Connections ein weiterer try/catch-Block im finally-Block des übergeordneten try/catch-Blocks nötig ist. Auch beim Schließen können Exc geworfen werden, die abgefangen werden wollen.

 

[Volvagia]

Stimmt auch wieder. Ich bin eher davon ausgegangen, dass der Benutzer möglichst gut informiert wird.
Ein close eines Streams/Reader/Writer gehört auf jeden Fall in ein finally. Ansonst noch das Unlock einer Lock-Klasse. Mehr das unbedingt hinein gehören fällt mir jetzt auch nicht ein. Ein finally-Block hat aber nur bedingt etwas mit Exceptions zu tun, ein try ist gültig, solange catch und finally in einer OR-Beziehung existieren (ich weiß, blöd ausgedrückt, aber das beide optional sind ist eigendlich auch falsch), ohne eins von beiden wird das try aber natürlich sinnlos und auch ungültig. finally wird, solange das Programm nicht terminiert wird, IMMER ausgeführt.
Vor kurzen hat jemand geschrieben, dass man darin sogar den returnwert der Methode "überschreiben" kann. Wäre aber dann sehr künstlerischer Code.

 

[traps12]

erstmals vielen dank für euren beitrag!

mir ist heute eine weitere frage eingefallen, die ich leider nirgendswo finden konnte.

unzwar:

wenn ich eine abgeleitete Klasse habe und die die methoden die ich in der basisklasse mit exceptions bearbeitet habe , muss ich dann automatisch die abgeleite klasse (falls ich die methoden überschreibe) mit exception handlen?

und falls ich in einer methode eine methode aufrufe(die aufgerufene methode eine exception hat) was muss ich dann machen?

wie sieht es mit interface aus??

danke im voraus

 

[remy]

eine interessante Frage

es verhält sich folgendermaßen: eine Unterklasse (abgeleitet) darf überschriebene Methoden enthalten, die weniger oder keine Exceptions schmeißt, andersrum geht das nicht: soll eine Unterklasse eine überschriebene Methode enthalten, die in der Oberklasse z.B. keinen modifier "throws" enthält, darf sie ebenfalls keine Exceptions "throwen". Ein Verstoß gegen diese Regel wird der Compiler nicht akzeptieren.
Das ganze gilt genauso für Interfaces.

Das ganze kann man sich logisch anhand von Polymorphie erklären. Nehmen wir als Beispiel die abstrakte Oberklasse Auto und die davon abgeleitete Klasse Audi. Nun haben wir noch ein Array vom Typ Auto, in dem sich Instanzen von Audis befinden.
Positivbeispiel: Autos haben die Methode "... abstract fahren() throws Exception", es kann also was schiefgehen. Möchten wir nun diese Methode auf die Autos im Array ausführen, müssen wir die mögliche Ausnahme behandeln, auch wenn die implementierte Methode in Audi keine Exception mehr schmeißt "... fahren()". In diesem Fall gehen wir also davon aus, dass die Methode fahren() bei Autos zu Problemen führen KANN, aber eine spezialisierte Klasse diese Methode so implementiert, dass gar kein Fehler mehr entsteht. Des weiteren könnte man sich vorstellen, dass eine spezialisierte Klasse "VW" die Methode "fahren() throws Exception" hat, was kein Problem darstellt, wenn wir allgemein Instanzen von "Auto" behandeln, denn wir fangen mögliche Ausnahmen ab. (Hoffe, es ist bis hierhin nicht zu verwirrend).

Negativbeispiel:
Die abstrakte Klasse "Auto" hat die Methode "abstract fahren()", die keine Exception schmeißt, also kein "throws". Wenn die spezielle Klasse "Audi" wieder die Methode "fahren()" ohne "throws" implementiert, haben wir kein Problem. Haben wir aber wieder die spezielle Klasse "VW", die die Methode "fahren() throws Exception" implementiert, sehen wir die potentielle Exception bei der allgemeinen Klasse "Auto" nicht mehr. Führen wir also "fahren()" auf eine VW-Instanz aus, die in einer Auto-Variable (oder auch Array) steckt, sehen wir hier nicht, dass "fahren()" auch eine Exception schmeißen kann. Kommt es dann zur Ausnahme, sind wir nicht vorbereitet und es knallt.

Die Behandlung von Exceptions können wir uns nur dann ersparen, wenn wir wissen, dass die Auto-Instanz tatsächlich ein Audi ist, der bei "fahren()" keine Exceptions schmeißt, d.h. die Instanz des Audis ist einer Variable vom Typ Audi zugewiesen (klappt natürlich nur beim Positivbeispiel).

Wie gesagt, ich hoffe, das ist irgendwie rübergekommen. Ansonsten kann ich auch noch zwei Code-Beispiele basteln.

 

[traps12]

hey vielen dank! ich habe es auch mit einem programm mal ausprobiert funktioniert! das mit der methode ist mir auch klar geworden: falls man in einer methode einen throw wirft und es in einer anderen methode verwendet muss es auch eine throw im methodenkopf besitzen.

viele grüße
traps12

 

[Volvagia]

RuntimeExceptions können aber immer gethrowt werden. *erwähn*