Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Testfälle 5.3
Ein paar Testfälle für die 5.3: https://wwwcip.informatik.uni-erlangen.de/~xu76puwe/aud-testcases/SkylineSolverTest.java
Wenn ich die Testfalldatei laufen lasse, bekomme ich einen Stack overflow in der Zeile wo bei mir conquer sich rekursiv aufruft…
wenn ich aber die Testfälle beispielsweise in die Datei lade, dann klappts einwand frei…
liegt der stackoverflow daran, dass der basisfall nicht passt?
Ein StackOverflowError klingt wie ein inkorrekter Basisfall. Welcher Testfall wirft denn den StackOverflowError?
der StackOverFlow kommt direkt nachdem ich “java SkylineSolverTest” eingebe
Wie sieht denn der Stack Trace aus? Die duplizierten Zeilen am Anfang kannst du weglassen.
Der was bitte?
P.S. hatte vor AuD nie etwas mit Informatik zu tun.
Ich habe mal geschaut ob b[0].length oder b.length irgendwann mal 0 sind. Aber das ist nie der Fall…
Wenn eine Exception geworfen und nicht abgefangen wird, wird der Stack Trace ausgegeben. Das sieht ungefähr so aus:
Exception in thread "main" java.lang.AssertionError: collatzSum(213, 0) was 0 but should be 1
at CollatzTest.testCollatzSum(CollatzTest.java:18)
at CollatzTest.testCollatzSum(CollatzTest.java:26)
at CollatzTest.main(CollatzTest.java:32)Der Stack Trace ist folgendermaßen zu interpretieren: Die erste Zeile “at CollatzTest.testCollatzSum(CollatzTest.java:18)” gibt dir an, in welcher Methode und Zeile die Exception geworfen wurde. In diesem Fall ist das die Methode CollatzTest.testCollatzSum bzw. die Zeile 18 in der Datei CollatzTest.java. Die Zeile darunter “at CollatzTest.testCollatzSum(CollatzTest.java:26)” gibt an, von wo aus die Methode aufgerufen wurde. In diesem Fall war das ebenfalls die Methode CollatzTest.testCollatzSum bzw. die Zeile 26 in der Datei CollatzTest.java. Jede weitere Zeile gibt nach dem gleichen Prinzip an, welche Methode zu dem aktuellen Methodenaufruf geführt hat.
Mit dem Stack Trace kannst du also herausfinden, welcher Testfall zu dem StackOverflowError geführt hat.
Mit Stacktrace ist die Fehlerausgabe gemein, die im Wesentlichen so aussieht:
java.lang.ArrayIndexOutOfBoundsException: 3
at example.common.TestTry.execute(Testtry.java:17)
at example.common.TestTry.main(Testtry.java:11)Edit: Damn, too late;)
ich bekomme folgendes:
Die letzten 10-20 Zeilen sind interessant. Die Zeile “at SkylineSolver.conquer(SkylineSolver.java:104)” wiederholt sich ein paar hundert mal, danach kommt das was zählt.
Ich kann aus der Aufgabenstellung nicht herauslesen, dass die Methode conquer auch mit leeren skyline-arrays gefüttert werden soll, man kann das aber natürlich mal mit abfangen. 
also bei mir steht überall diese Meldung
p.s
und ich habe aufgrund des letzten posts den letzten Testfall mit dem leeren array weggelassen und dann kommt keine Fehlermeldung mehr…
Du hast Recht, wie ich gerade feststellen musste. Die maximale Anzahl der Elemente im Stacktrace scheint begrenzt zu sein, wodurch du die ursprüngliche Ursache des StackOverflowErrors nicht mehr in dem Stacktrace siehst. Es gibt allerdings eine Möglichkeit, dieses Limit zu verändern. [0]
Wenn du denkst, dass nur nicht-leere Eingaben getestet werden, kannst du diesen Testfall natürlich weglassen. Ich bin diesbezüglich nicht sicher und nehme deshalb an, dass auch eine Skyline für 0 Gebäude getestet wird bzw. werden könnte.
So etwas ist in der Tat meist nicht notwendig (also Stacklimits veraendern).
Du rufst die Methode immer an der gleichen Stelle wieder auf. Das nennt man Endlosrekursion. Meist tritt das auf, weil man den Basisfall vergessen hat, oder einen Fehler bei der Abfrage des Basisfalls hat.
Wenn keine Ausgabe erfolgt, dann ist der Test bestanden,oder?
Und woher nimmst du an, dass wenn b gleich
null
ist ein Array mit {0,0} ausgegeben wird?
1 Like
Hab ich mich zu erst auch gefragt, aber das ganze wurde nicht weiter in der Aufgabenstellung spezifiziert, von daher hast du (meiner Meinung nach) 3 Moeglichkeiten, entweder du wirfst ne NullPointerException (, was wir eigentlich noch nicht behandelt haben), du gibst selbst ‘null’ zurueck, oder aber du gibst einen Array zurueck. Der zweiten wuerde ich immer die erste Moeglichkeit vorziehen und ne Exception werfen. Fuer die letzte Moeglichkeit kannst du dir ueberlegen, was denn genau dein Algorithmus macht, und, was du vielleicht mit dem Ergebnis (Also der Skyline) machen willst. Naja und mehr als ne einfache Repraesentation der Skyline und einfache Errechnung der Flaeche fiele mir grad nicht ein, womit ein leeres Array infrage kommt, aber genauso gut ein Array mit {0,0}, da das so gesehen auch die Ergebnisskyline mit keinen Gebaeuden repraesentiert, naemlich gar keine 
TLDR: Ohne Angaben koennen wir den Fall nicht loesen und muessen entscheiden, was wir fuer das beste halten. (Sollte aber imho nicht in die Bewertung mit einfliesen)
E: Anzumerken waere noch, dass ich das ganze auf (fuer mich) logischen Annahmen und meiner begrenzten Programmierkenntnisen geschlossen habe und keinerlei Erfahrung in groesseren Projekten habe, nicht alles was im Internet steht basiert auf fundamentierten Wissen.
Ja.
Den Fall, dass conquer mit null als Argument aufgerufen wird, teste ich nicht. Wie xenexi schon bemerkt hat, gibt die Aufgabenstellung in diesem Fall nichts vor. Ich teste allerdings den Fall, dass conquer mit einer leeren Gebäudeliste aufgerufen wird (new int {}). Meiner Interpretation der Aufgabenstellung nach soll in diesem Fall die Skyline {0, 0} zurückgegeben werden.