Fachrat Informatik - Forum

Quoted

Original von Warui
.oO(wieso nur habe ich das Gefühl, dass es länger gedauert hat, diesen Text zu schreiben, als die Aufgabe zu lösen? ^,^)

Die Aufgabe klingt wirklich einfach, das Problem ist eher, dass wir in unserer Blockzeit erst am Di um frühestens 11 Uhr erfahren, ob unsere eingeschickte Lösung von Üb9 was taugt, auf der wirs aufbauen sollen* Aber ich geh mal davon aus, dass Üb10 unabhängig genug davon ist, als dass da nix schief gehen kann...

(* Seitenhieb: Ja, es gibt eine Musterlösung, aber der trau ich auch nicht. Ich sag nur EreignisArray, Zeile 23 SCNR )

Quoted

Original von julianr
Ich sag nur EreignisArray, Zeile 23 SCNR )

Recht hast Du, wurde verbessert!

Brainbug

Seh ich es richtig,dass SimulationException eine abstract class ist und EreignisZuSpaet eine davon abgeleitete Klasse ja?
Und bei SimulationException müssen wir extends Exception machen oder?

Er sagt mir immer "unhandled exception type"

Quoted

Original von Dot
Seh ich es richtig,dass SimulationException eine abstract class ist und EreignisZuSpaet eine davon abgeleitete Klasse ja?
Und bei SimulationException müssen wir extends Exception machen oder?

Mach aus der SimulationException eine richtigeKlasse, die du von Exception ableitest. Man kann auch von richtigen klassen vererben, solange du dies nicht explizit verbietest. Ansonsten dürftest du über ein paar Dinge bei deinem Programm stolpern...

<edit>
Hier steht der Unterschied zwischen abstrakten und normalen Klassen beschrieben:
http://www.galileocomputing.de/openbook/…40001EA1F04F100

Da du Instanzen von SimulationException bilden musst, geht das so nicht.
</edit>

Ein paar Tipps:

In Aufgabe 1a steht, dass das Interface "IEreignis" eine Exception werfen soll.
Das geht so natürlich nicht, sondern gemeint ist, dass die Funktionen in dem Interface Exceptions werfen sollen. Und dies sollen auch nicht alle drei Funktionen tun, sondern nur die "ereignisAusfuehren".

Bei Aufgabe 1b sollen "Ankunft.ereignisAusfuehren" und "Abgang.ereignisAusfuehren" eine Exception werfen, falls die Ausführungszeit größer als 100 ist.
Dabei ist zu beachten, dass "Ankunft.ereignisAusfuehren" unter Umständen auch einen Abgang erstellt und bei diesem auch die Ausführungszeit überprüft werden muss!

Ich verstehe nicht, warum da in der Aufgabe so komische Vorgaben gemacht wurden. Es wäre sinnvoller gewesen, die Exception nicht in "ereignisAusfuehren", sondern in "setAusfuehrungszeit" zu werfen, dann hätte man solche Fälle sofort abgedeckt.
Deshalb hatte ich die Aufgabenstellung zuerst auch ignoriert und das so gelöst, aber dann kriegt man wiederum später das Problem, dass auch "Simulator.init" eine von "setAusfuehrungszeit" geworfene Exception weiterwerfen muss, was laut Aufgabe nicht verlangt war...

Noch was anderes:

Der Lösungsvorschlag zu Aufgabe 9 enthält in den Javadoc-Kommentaren Umlaute.
Beim Kompilieren auf UTF8-Systemen hat man dadurch lauter Warnungen. Es kann also vorkommen, dass auf dem Lösungsvorschlag basierende Lösungen zu Aufgabe 10 auf dem eigenen Rechner zwar Problemlos funktionieren, es dann aber bei der Vorstellung in der Uni zu Warnungen kommt, falls die Systeme da auf UTF8 eingestellt sind.

Kann vielleicht jemand Teil d ein bisschen erklären was damit gemeint ist?

Ich hab grade versucht den Lösungsvorchlagscode zu kompilieren und bekomme dabei über 40 Fehler. Wie soll man denn so die Aufgabe schaffen?

Wenn ich raten darf: Indem du dir die Fehlermeldungen anschaust und als Folge von diesen die Umlaute rausnimmst.

Nein, ich rede von richtigen errors, nicht warnings. Wenn's nur warnings wären ginge es ja trotzdem.

Das Problem ist, dass die SimulatorApplication.java inm implementions-Verzeichnis liegt. Das kann so natürlich niemals funktionieren...

Sollte eigentlich beim 1. compilieren auffallen ... egal

Kann ich nix dafür das is die Musterlösung.

Abgesehen von dem Problem mit den Umlauten lief der Lösungsvorschlag bei mir ohne weiteren Problemen.

Kompilierung mittels "javac simulation/implementation/SimulatorApplikation.java".

Da sind einige Sachen so, wie sie nicht sein sollten. Wenn man vorher an dem Classpath rumbastelt, mag das funktionieren.
Normaler weise packt man bei Programmen nicht das Hauptprogramm in ein Package. Das mag Java allgemein garnicht. Packt man die SimulatorApplikaton.java eine Ebene hoch muss man nurnoch die ganzen Package-Namen anpassen. Dann sollte es funktionieren.

Also, bei mir hat auch alles an Anhieb geklappt, komisch ...

naja... eine Main gehört definitiv nicht in ein Package. So sind Packages nicht gedacht. Packages sind für die Wiederverwendung von Code eingeführt worden. Eine Main verwendet man normalerweise so nicht wieder. Ansonsten baut man eine Unterklasse, in der die Dinge liegen, die wiederverwendet werden sollen. Zudem sollte ein Konstruktor immer public sein!

Quoted

SimulatorApplikation.java:17: Simulator() is not public in implementation.Simulator; cannot be accessed from outside package
Simulator meineSimulation = new Simulator();
^
1 error

So... für alle, die mit der Struktur der Musterlösung probleme haben, habe ich die mal geändert... Die Umlaute, die Probleme machen habe ich rausgenommen

Ich hatte damit zwar keine Probleme, als ich das ausprobiert habe, aber bitte, eine Version mehr kann ja nicht schaden. Im übrigen ein interessantes Beispiel dafür, was passiert, wenn man einen Modifier vergisst: durch das fehlende public ist der oben angesprochene Konstruktor implizit "package", also nur innerhalb des Packages sichtbar (was ja grundsätzlich kein Problem wäre, wenn man hier nicht versucht hätte, die main-Klasse aus dem Package zu rupfen - meiner Meinung nach übrigens nicht unbedingt nötig; denke, das ist Ansichtssache). Den Hinweis mit den Umlauten werde ich ab sofort berücksichtigen.

Brainbug