Hallo zusammen,
habe etwas komischen entdeckt, zumndest für mich Anfänger. Als Aufgabe müssen wir eine Simulation bearbeiten. Gewisse Teile (Klassen) der Simulation sind schon gegeben und es geht darum sie zu erweitern oder zu verändern.
Die Simulation sieht dann wie folgt aus:
Das wait war schon da und der grund ist die Darstellung der Simulation. Ohne Pause sieht man also eighentlich nichts. Macht zack und vorbei ist die Simulation.
Der einzelene Schritt:
Hier passiert viel mit linkedlisten wie Iterieren, hinzufügen und entfernen. LinkedlIst weil ich die Listen als Queue brauche.(Allerdings nicht unbedingt als FIFO Queue). Neue Elemente könnnen auch irgendwo in der mitte eingeführt werden. Es ist eine Liste mit Orten (Ort = Koordinaten auf einem grid). Der nächste Ort zur aktuellen position ist dann jeweils an erster Stelle, ein neuer ort wird entsprechend seiner Distanz zum aktuellen ort eingeführt.
(Ka ob das überhaupt relevant ist für das Problem, auf jedenfall passiert viel mit Listen).
Das Problem:
Ein bestimmter actor verursacht in seiner act-methode gelegentlich eine NoSuchElementException bei list.removeFirst(). Das Problem ist mir erst aufgefallen, als ich im Simulator eine Methode eingeführt habe ohne wait und ohne gui, die 100 Simulationen a 500 Schritten aufs mal durchführt und paar mittelwerte berechnet. Der Fehler tritt also selten auf, zum teil gar nie pro 100 Simulationen a 500 Schritten(auch mehrere male hintereinander nicht). Vom betroffenen actor gibt es 2 instanzen.
Hab das ganze auch per Papier durchgespielt und es sollte funktionieren, eg. ich sehe nicht ein wieso die List plötzlich kein Element mehr hat. Es ist richtig, dass ich vor der Methode keine Prüfung habe, aber die Prüfung braucht es theoretisch nicht, denn wenn die Liste an der Stelle leer ist, ist sowieso was falsch, logischer Fehler bei gewissen seltenen Situationen.
Die Frage ist es, wie man da vorgeht, um den Fehler zu finden.
habe etwas komischen entdeckt, zumndest für mich Anfänger. Als Aufgabe müssen wir eine Simulation bearbeiten. Gewisse Teile (Klassen) der Simulation sind schon gegeben und es geht darum sie zu erweitern oder zu verändern.
Die Simulation sieht dann wie folgt aus:
Java:
public void run(int numberOfTurns, int waitBetweenTurns)
{
for(int i = 0; i < numberOfTurns; i++){
step++;
step();
wait(waitBetweenTurns);
}
printResults();
}
Das wait war schon da und der grund ist die Darstellung der Simulation. Ohne Pause sieht man also eighentlich nichts. Macht zack und vorbei ist die Simulation.
Der einzelene Schritt:
Java:
public void step()
{
for(Actor actor : actors) {
actor.act();
}
}
Hier passiert viel mit linkedlisten wie Iterieren, hinzufügen und entfernen. LinkedlIst weil ich die Listen als Queue brauche.(Allerdings nicht unbedingt als FIFO Queue). Neue Elemente könnnen auch irgendwo in der mitte eingeführt werden. Es ist eine Liste mit Orten (Ort = Koordinaten auf einem grid). Der nächste Ort zur aktuellen position ist dann jeweils an erster Stelle, ein neuer ort wird entsprechend seiner Distanz zum aktuellen ort eingeführt.
(Ka ob das überhaupt relevant ist für das Problem, auf jedenfall passiert viel mit Listen).
Das Problem:
Ein bestimmter actor verursacht in seiner act-methode gelegentlich eine NoSuchElementException bei list.removeFirst(). Das Problem ist mir erst aufgefallen, als ich im Simulator eine Methode eingeführt habe ohne wait und ohne gui, die 100 Simulationen a 500 Schritten aufs mal durchführt und paar mittelwerte berechnet. Der Fehler tritt also selten auf, zum teil gar nie pro 100 Simulationen a 500 Schritten(auch mehrere male hintereinander nicht). Vom betroffenen actor gibt es 2 instanzen.
Hab das ganze auch per Papier durchgespielt und es sollte funktionieren, eg. ich sehe nicht ein wieso die List plötzlich kein Element mehr hat. Es ist richtig, dass ich vor der Methode keine Prüfung habe, aber die Prüfung braucht es theoretisch nicht, denn wenn die Liste an der Stelle leer ist, ist sowieso was falsch, logischer Fehler bei gewissen seltenen Situationen.
Die Frage ist es, wie man da vorgeht, um den Fehler zu finden.