432 433
434 435
Auf dieser und den beiden folgenden Folien wurde jeweils ein neues Objekt der Klasse FigurMalerei erstellt und die angegebene Methode ausgeführt. 436 437
438 439
440 441
442 443
Die verkürzte Überschrift soll andeuten, dass hier die Probleme mit möglichen null-werten nicht betrachtet werden. Wichtig ist allerdings, dass es eine equalsund ein hashcode-methode gibt. Die verkürzte Überschrift soll andeuten, dass hier die Probleme mit möglichen null-werten nicht betrachtet werden. Wichtig ist allerdings, dass es eine equalsund ein hashcode-methode gibt. 444 445
446 447
Mit der Methode values() erhält man eine Sammlung von allen Value-Objekten, die sich aktuell in dem HashMap-Objekt befinden. Die Berechnung dieses Ergebnisses ist sehr aufwändig. Wenn diese Methode häufiger im Programm steht, viel wichtiger aber häufig im laufenden Programm genutzt wird, sollte man über die Nutzung einer anderen Sammlung nachdenken. Die Methode remove liefert als Ergebnis das gelöschte Value-Objekt. Falls kein Objekt an der angegebenen Key-Position gefunden wurde, ist das Ergebnis null. Man beachte, dass bei dieser Methode vorher eine Schleife notwendig war, auf die jetzt verzichtet werden kann. 448 449
450 451
452 453
Die Verwaltung wird um eine Objektvariable semester erweitert in der das aktuell betrachtete Semester drinsteht. Der genau Prozess des Ladens und Speichern wird später genauer analysiert. Hier soll zunächst das Prinzip mit einer Realisierungsmöglichkeit erklärt werden. Parallel dazu wird der Umgang mit Exceptions beschrieben. Hinweis: Es werden hier 8-Bit-Versionen der Streams betrachtet (gibt ähnliche Klassen für Uni-Code, 16 Bit). 454 455
Das Schließen von Dateien ist ein sehr zentraler Schritt, da ein Vergessen dieser Aktion oftmals nicht direkt zu einem Fehler führt. Man spricht von einem schleichenden Fehler, der oft erst später gespürt wird, wenn eine Applikation deutlich langsamer läuft oder sich das Betriebssystem plötzlich weigert, eine bestimmte Aktionen, die sonst immer möglich sind, auszuführen. Der Dateiname ist beliebig, die Endung aber sinnvoll, da eine syntaktische korrekte XML-Datei erzeugt wird. Die genaue Kenntnis von XML ist hier nicht notwendig, aber leicht erlernbar und sollte irgendwann im Studium genauer verstanden werden. 456 457
458 459
Die Idee der mehrfach geschachtelten Konstruktoren wird später erklärt, wichtig ist hier nur, dass ein Stream zu einer Datei geöffnet wird und so Informationen in die Datei geschrieben werden. Anmerkung: Das Exception Handling wurde in Java 7 etwas vereinfacht. Da es hier um die Grundlagen geht, die in der präsentierten Form in anderen Programmiersprachen sehr ähnlich sind, wird die klassische Variante vorgestellt. Diese Variante ist natürlich auch in Java 7 nutzbar. 460 461
462 463
Die Zeilen "normalesprogramm" stehen für einfache Programmzeilen, die keine try-catch-blöcke enthalten. Es sind beliebig viele catch-blöcke möglich. Der finally-block kann weggelassen werden, wenn er existiert, wird er immer garantiert ausgeführt. Der angedeutete Fall2 wird später behandelt, falls es keinen finally-block gibt, wird die Exception direkt an die aufrufende Methode weitergegeben. Durch die verwendete Klasse XMLEncoder werden alle mit writeobject(.) geschriebenen Objekte im XML-Format abgespeichert. Dies ist möglich, da die Bean-Eigenschaften genutzt werden, bei denen durch get- und set- ein einfaches Lesen und Schreiben möglich ist. XML ist eine sogenannte Auszeichnungssprache mit einfachen syntaktischen Regeln. Basierend auf diesen Regeln kann man eine Teilmenge von XML- Dokumenten definieren, die zur Verwaltung bestimmter Daten genutzt werden können. XML ist dabei recht einfach maschinenlesbar, jede ordentliche Programmiersprache bietet Bibliotheken zur XML-Bearbeitung, und kann auch von Menschen gelesen und notfalls geschrieben werden, was häufig in Konfigurationsdateien genutzt wird. Das Thema XML wird in späteren Vorlesungen des Studiums vertieft. 464 465
Der Hintergrund des Problems ist es, dass BlueJ selbst als Java-Programm die Ausführung der Java-Programme steuert. Bei dieser Steuerung ist leider nicht sichergestellt, dass alle benutzten Klassen auch zur Nutzung mit XMLDecoder zur Verfügung stehen. Dies ist eine der wenigen Programmzeilen, die man nur hinschreiben, aber noch nicht verstehen muss. Wird das Java-Programm außerhalb von BlueJ genutzt, ist die Ergänzung überflüssig, schadet aber bei den vorgestellten Programmen auch nicht. 466 467
Man kann auch vollständig auf die Klasse File hier verzichten. Sie ermöglicht aber eine genauere Analyse des Fehlerfalls und kann deshalb hilfreich sein. 468 469
Die Warnung bezieht sich nur auf das Casten der Liste, da der genaue Typ der Liste, d. h. welche Objekte in ihr gespeichert sind, nicht explizit mit abgespeichert wird. (Längere Geschichte, da erst mit Java 5 die Möglichkeit entstand, den Typen der Listenelemente anzugeben) 470 471
472 473
474 475
Der Testfall zeigt, dass die Ausgangssituation mit zwei IMI- und MID-Studenten abgespeichert wird, danach zwei Studiengänge gelöscht und dann die gespeicherten Daten wieder eingelesen werden. Da keine Exception erwartet wird, steht im catch-block ein "asserttrue(false)", was dazu führt, dass, wenn diese Anweisung erreicht wird, immer ein Fehler erzeugt wird. Generell gilt bei JUnit, dass nicht behandelte Exceptions wie Fehler behandelt werden und so zu einem erfolglosen Testfall führen. 476 477
Wieder wurde die Programmstelle, von der man erwartet, dass sie nicht erreicht wird, mit asserttrue(false) gekennzeichnet. Alternativ könnte hier auch fail() stehen, was auch nur bedeutet, dass die eigentlich nicht zu erreichende Programmzeile doch erreicht wurde. Die Zeilen "normalesprogramm" stehen für einfache Programmzeilen, die keine try-catch-blöcke enthalten. Tritt in machwas eine Exception vom Typ ExTyp2 auf, wird diese an die aufrufende Methode weitergeleitet. Da die Exception hier nicht gefangen wird, muss sie in der throws-deklaration von rufauf stehen. 478 479
480 481
Natürlich kann man auch andere Konstruktoren nutzen, Objektvariablen definieren und Methoden ergänzen. Dies kann z. B. Sinn machen, wenn man die Fehlerbehandlung weiter konkretisieren möchte. 482 483
484 485
Das Bild zeigt nur einen recht kleinen Ausschnitt aller bereits existierenden Klassen zur Fehlerbehandlung. Es fällt auf, dass es die noch allgemeinere Klasse Throwable als Grundlage gibt, wobei es üblich ist, eigene Exceptions von der Klasse Exception erben zu lassen und gegebenenfalls einen eigenen Exception-Vererbungsbaum aufzubauen. Alle von Error erbenden Klassen stehen für gravierende Fehler, die man in der eigenen Software nicht behandeln sollte, und teilweise gar nicht behandeln kann. Da jede Programmausführung Speicher benötigt, ist es unklar, ob auf "OutOfMemory" reagiert werden kann. Auch die von RuntimeException erbenden Klassen stehen meist für größere Fehler, können aber gegebenenfalls wie eine IllegalArgumentException abgefangen werden. Für die bisher genannten Klassen gilt, dass sie nicht in einer throws-liste stehen müssen, da in Java keine Behandlung des Fehlers erwartet wird. Die Klassen können aber trotzdem in throws-listen stehen und mit catch- Blöcken bearbeitet werden. Die "normalen" Exceptions müssen immer mit try-catch-blöcken behandelt werden. 486 487
488 489