Hey, jetzt geht's weiter mit Exceptions, Exceptions werden zur Fehlerbehandlung eingesetzt,
denn es gibt zwei Sorten von Exceptions, geprüfte und ungeprüfte Exceptions.
Ungeprüfte Exceptions werden zur Behandlung von Programmierfehlern eingesetzt. Das sind Fehler,
die der Programmierer nicht vorhersehen kann,
weil wenn er den Fehler vorhersehen würde,
würde er ihn einfach nicht machen,
auf den er aber auch Einfluss hat oder auf die Entscheidung der Fehler,
hat der Einfluss,
weil er könnte
den Fehler einfach nicht machen
Beispiele für ungeprüfte Exceptions sind zum Beispiel Nightpointer Exceptions oder Index out of Bounds Exceptions.
Sowas haben wir in SE1 öfter mal gekriegt.
Geprüfte Exceptions werden zur Behandlung von Umgebungsfehlern eingesetzt. Umgebungsfehler kann
der Programmierer zwar vorhersehen, er hat aber keinen Einfluss darauf.
Ein Beispiel wäre zum Beispiel eine Methode versucht, etwas auf
den Drucker zu schicken und der Drucker ist einfach aus.
Oder aufs Internet zuzugreifen, aber der Router ist aus oder die Adresse stimmt nicht.
Oder zum Beispiel auch etwas in einen Pfeil zu schreiben
Und das Pfeil, der Pfad zu dem Pfeil ist zum Beispiel falsch.
Oder das Pfeil ist Schreibgeschützt. Und wir haben also nicht die Rechte,
darauf zuzugreifen oder aus irgendeinem Grund können wir unseren Pfeilwriter nicht wieder schließen.
All das wären Umgebungsfehler. Sie sind prinzipiell vorhersehbar.
Wir haben aber keinen Einfluss darauf, unter Umständen,
ob jetzt dieses Pfeil Schreibgeschützt ist oder nicht.
Für den Umgang mit geprüften Exceptions gibt es in Yara
das Konstrukt Try Catch
Dabei steht in einem Tri-Block, all das, was potenziellen Fehler auslösen könnte.
Und in einem Catch-Block steht einfach das drin,
was dann passieren sollte, wenn der Fehler ausgelöst wird.
Und wir hatten vorhin ja schon Steuerung 1.
Also ich gehe jetzt hier auf das unterkringelte Steuerung 1
und gehe auf Surround with Try Catch.
Dann machte mir hier so ein wundervollen Tri-Block um die erste Zeile.
Das hier kann aber potenziell diese beiden zeigen können,
potenziell auch Fehler werfen
Jetzt kommt im Prinzip ein zweiter Shortcut der Woche. Ich markiere das nämlich,
gehe auf alt und gehe mit der Pfeil nach oben taste.
Ich verschiebe das mit der Pfeil nach oben, taste einfach den ganzen Block nach oben.
Ich finde das eigentlich immer ganz praktisch. Also nochmal,
das, was man verschieben will, markieren,
alterste Pfeil hoch oder runter, verschiebt es nach oben oder unten.
Und jetzt haben wir hier in unserem Triblock all das,
was potenziell Fehler werfen könnte. Und in unserem Catchblock steht einfach nur,
gibt das auf der Konsole aus, was so an Fehlermeldung da ist, den Stack-Trace.
Wenn wir das jetzt mal speichern, und mit Start-up,
Run as Java-Application, das Ganze laufen lassen,
dann sehen wir, dass hier ein Textfall erstellt wurde,
wenn ich da draufklicke, die DVD,
Schrödinger und seine Katzen wurde verliehen an Vicky.
Also wurde es da reingeschrieben. Krima. Jetzt wollen wir
aber mal sehen, was passiert,
wenn das hier oben nicht sauber ausgeführt werden kann und
wir in den Catchblock gehen
Dazu mache ich jetzt diese Datei, einfach mal schreibgeschützt,
hier über Eigenschaften, Zugriffsrechte, Lesen und Schreiben, nur lesen.
Wenn ich jetzt das Ganze hier ausführe,
Ronness Java Application, dann sieht man hier unten,
Java IO, File Not Found Acception,
das ist ein bisschen irreführend, weil direkt dahinter steht,
vermischen die Neid.
Er hat also das File gefunden,
es war da,
aber wir hatten keine Zugriffsrechte da drauf
Dementsprechend wurde dann hier diese Fehlermeldung geworfen. Jetzt ist es allerdings so,
dass so der durchschnittliche Benutzer,
wenn er ein Programm ausführt,
nicht gleichzeitig dabei in die Java-Konsole laufen hat,
auf der dann hier so eine Fehlermeldung ausgegeben wird und er sieht sich das an.
Also zu diesem Prinz-Deck-Trace gibt es eine schönere Alternative.
Und die gucken wir uns jetzt mal an.
Dafür gibt es zum Beispiel
J. Option Pain
Jay Option Pain, da haben wir es. Und dann haben wir
die Methode Show Message Dyerlock, in dem diese hier.
Und jetzt möchte er zuerst eine Parent-Komponente haben.
Das liegt daran, dass bei grafischen User Interfaces oft so
ein Fensterchen aufgemacht wird von einem anderen grafischen User-Interface.
Und die hängen irgendwie zusammen. Oder von einer
anderen grafischen User-Interface-Komponente. Hier haben wir das aber nicht.
Also sagen wir, nein, die Message ist zum
Beispiel Schreiben
Hat nicht geklappt. Der Titel ist, meinetwegen,
Fehler, Meldung. Und dann der Message-Type,
da können wir wieder J. Option Pain nehmen.
Und dann Punkt Error Message
So. Okay, und wenn wir das Ganze jetzt nochmal machen,
und hier die Datei ist halt immer noch schreibgeschützt,
Start-up, Run as Java Application,
dann geht hier so ein Fensterchen auf,
Fehlermeldung ist hier unser Titel, Schreiben hat nicht geklappt.
Unsere Fehlermeldung und durch Geoction Pain Error Message ist hier dieses
Kreuz zustande gekommen. Da gibt es auch noch Fragezeichen,
Ausrufezeichen, irgendwelche anderen Symbole,
aber da ist ja jetzt hier
eine Fehlermeldung ist
Nehmen wir dann einfach dieses Kreuz. Gut, jetzt haben wir
natürlich noch ein Problem. Es wird versucht, alles,
was hier in diesem Tri-Block drin ist, auszuführen.
Und sobald irgendwas nicht gelingt, wird alles danach nicht mehr ausgeführt,
sondern es wird dann in den Catchblock gegangen und dann wird unsere wundervolle Fehlermeldung ausgegeben.
Jetzt ist es aber so, dass wir in jedem Fall
unseren Ride-Stream wieder schließen wollen. Das heißt, das,
wo hier jetzt der Cursor steht, writer.close soll in jedem Fall ausgeführt werden.
Dafür gibt es dann das Konstrukt Finally. Wenn ich hier jetzt
schreibe Finally und mache dann noch so einen Blog da drunter,
dann könnte ich das hier einfach da rein verschieben.
Und das würde dann in jedem Fall ausgeführt werden. Egal,
ob es hiervor zu einer Fehlermeldung kommt oder eben auch nicht.
Aber wir sehen, hier ist es schon wieder rot unterkringelt
Das liegt daran, dass er das Schließen auch nicht klappen könnte,
wenn ich hier draufgehe, sieht man gleich, Unhandled Exception,
Type, IO Exception, IO steht für Input Output.
Also könnte ich jetzt hier auch wieder mit Steuerung 1
draufgehen und sagen, surround with try catch.
Jetzt meckert er das wieder an,
weil er hier aus diesem Block nicht auf Writer zugreifen kann.
Jetzt könnte ich das hier ausschneiden und als Exemplarvariable machen
Dann kennt er Writer hier, aber nichtsdestotrotz haben wir hier einen Try-Catch-Block in einer Fehlerbehandlungs-,
in einem Fehlerbehandlungskontext, nämlich in einem Finaly-Block.
Das ist nicht so besonders elegant. Wir kommen nicht drum rum,
wenn wir außer dem Schließen einer Ressource auch noch andere Aufräumarbeiten durchführen wollten,
dann bräuchten wir einen Finaly-Block, weil wie gesagt, alles,
was im Finaly-Block steht, wird auf alle Fälle ausgeführt,
egal ob es vorher zu einem Fehler gekommen ist oder nicht.
Es gibt aber eine Alternative, mit der das eigentlich ein Stückchen schöner geht.
Ich hole jetzt mal mit Steuerung Z das Ganze wieder zurück,
hoffentlich.
Da sind wir
Mach meinen Close, kann ich mir eigentlich sparen.
Das heißt, ich mache jetzt erst mal diesen Finaly-Blog weg.
Er geht bis da. Und es gibt was in Java,
das heißt Try with Resources. Das ist für alles,
für jede Ressource, die am Ende ein Schließen erfordert,
ist das anwendbar. Dann mache ich hier runde Klammern rein,
mache hier die Deklaration von dem Writer,
schneide ich mir hier aus
Und pack sie hier rein. Und das hier schneide ich
mir auch aus. Man packst hier oben rein.
Und dann brauche ich diese Zeile auch nicht mehr.
Und ich brauche auch das Close nicht mehr. Das heißt also,
es wird versucht, mit dieser Ressource das zu tun,
was im Triblock steht.
Und egal, ob das gelingt oder nicht gelingt,
wird auf alle Fälle die Ressource am Ende
wieder geschlossen
Das ist jetzt eine Möglichkeit der Fehlerbehandlung,
nämlich die Fehlerbehandlung, direkt in der Methode,
in der das, was potenziellen Fehler werfen kann,
nämlich hier das Aufrufen des Konstruktors oder hier das Schreiben oder auch das Schließen,
das sind die Dinge,
die hier potenziellen Fehler aufrufen oder werfen könnten und man kann es halt direkt in der Methode,
in der das benutzt wird,
abfangen.
Es gibt aber auch noch eine Alternative und diese Alternative zeige ich euch gleich,
dafür mache ich eben mein ganzes Dry-Catch-Gedöns wieder weg.
Also das funktioniert so und das ist auch gut so.
Ich will euch nur eine Alternative zeigen. Ich schneide das hier wieder aus,
tu das nach oben. Das nehme ich hier raus.
Ein Pucks. Obwohl ich brauche hier diesen Pucks dahinter.
Da ist hier nämlich auch aus dem Triblock raus,
in dem ich nach oben verschiebe, brauche ich natürlich wieder Ein Close.
Also ich führe im Prinzip eigentlich nur die Situation herbei,
die wir vorher hatten,
weil ich euch eine Alternative zur Fehlerbehandlung direkt in der Methode zeigen möchte.
Wir sehen, es ist auch alles wieder wundervoll rot.
Ich kann jetzt sagen, ich will den Fehler nicht hier behandeln,
derjenige, der die Methode protokolliere,
aufgerufen hat,
soll gefälligst
diesen Fehler behandeln
Das ist auch eine Alternative, die mir angeboten wird,
wenn ich hier auf Steuerung 1 gehe, nämlich die allererste Atthrows Declaration.
Ich klicke hier drauf. Ja, es ist eine AO-Exception
. Damit habe ich hier im Prinzip deklariert,
dass meine Methode protokolliere, eventuell eine AO-Exception werfen könnte.
Jetzt ist hier unten nichts mehr rot,
aber hier oben in der Methode Verleihe an,
in der protokolliere,
aufgerufen wird
Ist das jetzt rot unterkringelt, weil hier eine unbehandelte Exception ist? Jetzt könnte ich,
ich gehe hier immer wieder mit Steuerung eins drauf,
jetzt könnte ich wieder eine Throws Declaration hier oben für Verleihe
an hinzufügen und dann müsste ihm derjenige, der Verleihe an aufruft,
entweder die Exception handeln oder wieder weiterwerfen.
Ich mache hier aber einfach mal Surround with Trial Catch und dann haben wir es hier,
jetzt haben wir hier unten wieder unser hässliches Print Stack Trace,
aber wie man das in so ein schöneres Wie man das mit so einem schönen Fensterchen macht,
das habt ihr ja gesehen.
Und jetzt könnte ich euch vielleicht zum Schluss noch zeigen,
was uns denn dieses Ganze, diese ganze Fehlerbehandlung eingehalten,
oder die Notwendigkeit zur Fehlerbehandlung eingehandelt hat.
Wenn ich hier nämlich auf Filewriter gehe und mache Steuerung 3
, dann wird die Java-Eigene klasse Filewriter aufgerufen.
Und schon sehen wir hier im Konstruktor
die Throws Declaration
Das heißt also, da wird schon gesagt,
beim Erzeugen des Filewriters könnte irgendwas schiefgehen.
Deswegen sagen wir, die Klasse oder der Konstruktor,
der Klasse Filewriter, wirft eine Exception.
Und das hat gefälligst derjenige, der der Aufrufer von Filewriter
ist, zu behandeln. Und das waren wir. Jetzt
haben wir es weitergereicht an auch unsere eigene Methode Verleihe an
und haben hier gesagt,
behandel es hier
Und das Gleiche kann man sich zum Beispiel auch für die Methode Ride oder Close angucken.
Jetzt sind wir hier an der Seite,
dass Filewriter eigentlich nur aus Konstruktoren besteht,
aber wir sehen hier oben, der Filewriter,
App von Output-Streamwriter, dann gehe ich jetzt da wieder drauf.
Sag F3, also eigentlich sage ich nicht nur F3,
ich drücke auch F3 und sehe hier die ganzen Methoden,
wenn ich hier auf Ride gehe,
sehe ich auch hier Throws IIO Exception und bei Close
habe ich genau das Gleiche
Ja, das heißt also schon, diejenigen, die hier,
die Java-eigenen Methoden geschrieben haben, haben gesagt, oh,
da könnte potenziell was schiefgehen, wer weiß,
ob derjenige, der mit einem Filewriter was tun will,
überhaupt auf das File zugreifen kann oder ob irgendwelche anderen Dinge sind,
dann sagen wir hier mal,
das wirft eine IO-Acception und dann muss sich derjenige,
der Filewriter benutzen will,
eben darum kümmern.
So, ich mache jetzt hier mal diese Klassen wieder zu
und im Prinzip war es das heute auch schon von mir,
es war heute irgendwie eine Ja, ein deutlich kürzerer Hands-on-Teil,
aber ich glaube, ich habe euch so das Wichtigste gezeigt.
Ich glaube, das ist so auch ziemlich viel von dem,
was in dem Aufgabenblatt fünf drin vorkommt.
Dementsprechend hoffe ich, dass ich euch damit ein bisschen weiterhelfen konnte.
Vielleicht dann noch ein Tipp zum Schluss. Dieser Einteilung in
geprüfte und ungeprüfte Exceptions ist eine einigermaßen beliebte Klausuraufgabe.
Also es kann durchaus sein, Ich stelle die Klausur nicht.
Ich weiß nicht, wie die Klausur aussieht,
bis ich anfange, sie mit den anderen Betreuern zusammen zu korrigieren.
Aber so die Erfahrung der Klausurkorrektur zeigt,
dass ziemlich gerne mal so Listen sind,
wie ihr habt verschiedene Exceptions, IO-Exception, Nightpointer Acception,
in ex out of bounds acception und ihr müsst dazu schreiben,
ob es eine geprüfte oder ungeprüfte Acception ist oder ihr bekommt quasi sowas wie,
kann ich auf den Drucker zugreifen?
Versucht auf ein Element zuzugreifen, das außerhalb der Grenzen von einem Array liegt.
Also solche Beschreibungen und ihr müsst dann dazuschreiben,
ob es ein Umgebungsfehler oder ein Programmierfehler ist.
Nur so meine Empfehlung, guckt euch das nochmal ein bisschen genauer an.
Okay, und das war es dann jetzt auch von mir
für heute und wir sehen uns nächste Woche