statt eines booleans (was der Typ sein sollte) einen int z.b reinschreibt?
Das kann ja gar nicht passieren. Die Methode bekommt boolean[] als Parameter, daher kann da nichts anderes übergeben werden. Die Sorge hast Du nicht.
Da Du von einem Anwender sprichst, der da etwas rein geben könnte: Bitte immer den Fokus behalten: Du testest hier eine Methode. Da ist nichts mit einem Anwender. Du musst also nur die Methode betrachten und die Methode ist sogar noch sehr einfach, denn sie basiert auf keinem inneren Zustand. Also keine Abhängigkeiten in der Art. Du hast nur zwei Eingaben und musst da bei allen Fällen schauen, was dabei raus kommt.
Da meine Methode als Rückgabewert einen int hat (die Anzahl der Unterschiede der beiden arrays) kann ich auch nicht mit array.length arbeiten
Du musst natürlich klar definieren, was das Resultat sein soll bei welcher Eingabe. Und da hast Du viele Möglichkeiten:
a) undefined: Wenn Du mir Schrott gibst, dann bekommst Du irgendwas zurück. Keine Ahnung was. Interessiert mich auch nicht.
==> Das ist die schlechteste Variante, die man wählen kann. Wenn eine Eingabe nicht in Ordnung war, dann sollte die Methode dies immer klar signalisieren um zu verhindern, dass mit dem Fehler weiter gearbeitet wird.
b) Du schaust, ob und wie Du Fehler in der Rückgabe signalisieren kannst. Ggf. ist dann noch der Rückgabetyp anzupassen.
==> Das ist schon besser. Bei Deiner Methode wären negative Werte denkbar. -1 wird zurück gegeben, wenn die Eingabe ungültig war. Andere Dinge, die man oft findet: Es wird eine Referenz zurück gegeben (also bei Dir z.B. Integer) - dann kann man null zurück geben. Oder man nutzt Typen wie Optional<T>. Dies ist aber immer noch nicht gut, denn Du musst nach dem Aufruf immer die Rückgabe prüfen. Das bläht den Code aber auf.
c) Wenn ein Fehler auftritt, dann wird eine Exception geworfen. Wenn einer der Parameter null ist, dann wird eine NPE geworfen (egal ob absichtlich oder unabsichtlich
). Wenn die Arrays unterschiedliche Länge haben, dann wird eine andere Exception geworfen ...
==> Das ist der Weg, der durchaus üblich ist.
Bezüglich Exception werfen: Das soll nur passieren, wenn eine Ausnahme eintritt. Also etwas, das nicht zu erwarten war. Wenn ich eine Methode bereit stelle, dann erwarte ich, dass der Entwickler, der diese nutzt, diese richtig nutzt. ==> Ausnahme
Der Nutzer vertippt sich => Das passiert immer, also keine Ausnahme!
Die Regel hier besagt: Exceptions sollten nicht für den normalen Programmablauf genutzt werden! Also Dinge, die alles mögliche sein können, immer erst prüfen. Also wenn eine Methode wie in b) angedeutet auch null zurück geben kann: Bitte Prüfen!
