Warum will die MEthode noch am Ende einr eturn

[okayjetztgehts]

public int groß(Klassenname test) {
    Klassenname test2 = new Klassenname();
    boolean boolean1 = false;
    boolean boolean2 = false;
    if (test.intarray.length == test2.intarray.length) {
        for (int i = 0; test < u.zeichen.length; i++) {
            if (test.intarray[i] == test2.intarray[i]) {
                boolean1 = true;

            } else {
                boolean = false;
                return 2;
            }
            return 94;
        }
    } else if (test.intarray.length < test2.intarray.length) {
        for (int i = 0; i < test.intarray.length; i++) {
            if (test.intarray[i] == test2.intarray[i]) {
                boolean2 = true;
            } else {
                boolean2 = false;
                return 33;
            }
        }
        return 1;
    } else if (test2.intarray.length < test.intarray.length) {
        for (int i = 0; i < test2.intarray.length; i++) {
            if (test.intarray[i] == test2.intarray[i]) {
                boolean2 = true;
            } else {
                boolean2 = false;
                return 39;
            }
            return 2;
        }
    }
}

Ich habe das Problem, dass meine MEthode am Ende noch ein return Statemen tmöchte, obwohl dieses reutrn niemals erreicht werden würde, aber der Kompilier mächte es so. Nun meine Frage, wie kriege ich das gefixxt, habe versucht mit dem Code zu spielen und habe z, B. das else if weggelassen und nur ein else gneommen, hatte trotzdem das gleiche Problem.

Ist es zudem auch erlaubt einfach einen leeren return hinzusetzen, wie return 0? Dieser return würde eh nicht erreicht werden und mein Programm compilieren oder wäre das ein Fehler?

Würde mich freuen, wenn jemand den Code so umformen würde, dass man kein return mehr setzen muss und vllt. weiß ja jemand auch, ob dummy returns üblich wären, wie dass ich hier einfach ein return setze, damit es compiliert wird, aber das return halt keine Relevanz hätte, da es ja nie erreicht würden wäre wegen den ifs

 

[Jw456]

Ein return 0 am Ende kannst Du machen.
Das das nie erreicht wird sieht der Compiler anders.
Und zwar im Else der ersten if ist am ende kein return.
Auch wenn vielleicht deine Programm Logik so ist das du da nie hin kommst. Das prüft der Compiler nicht er sieht das nur strukturiert. Und da ist es möglich ohne return die Methode zubeenden.

Also füge es ein und es ist gut.

 

[mrBrown]

Wenn du sicher bist, dass das Ende nie erreicht wird, kannst du dort mit throw new AssertionError(); einen Fehler werfen. Damit ist dann sowohl zur Laufzeit klar, das etwas nicht passte, als auch beim Code lesen offensichtlich, dass man nie dorthin kommen sollte – beides ist mit einem return 1 nicht gegeben.
Dem Error kannst du auch noch eine Message mitgeben, damit deutlicher wird, warum das nicht möglich ist.

 

[mrBrown]

Das das nie erreicht wird sieht der Compiler anders.
Und zwar im Else der ersten if ist am ende kein return.

In jedem else-Block gibt es ein Return.
test2.intarray.length == 0 ist aber zB ein Fall, der nicht mit einem Return beendet wird.

 

[kneitzel]

Das Pattern so ist schlicht schlecht.

Es kann nur die drei Möglichkeiten geben:
a==b
a < b
a > b

Was anderes ist nicht möglich.

Daher ist es in meinen Augen ein Unding, dies abzuprüfen. Code Stellen wie:

if (...) {
    // ...
} else if (...) {
    // ...
} else if (...) {
    // ..
}

"riechen". Das ist also immer sofort etwas, das ich betrachten würde um zu schauen, ob da ein Refactoring Sinn macht.

In Deinem Fall ist es eindeutig: Du hast eine Aufteilung in 3 Teile und das wäre dann ein:

if (...) {
    // ...
} else if (...) {
    // ...
} else {
    // ..
}

==> Das letzte if fliegt einfach raus. Ist ja auch klar: Wenn nicht a==b gilt und auch nicht a < b, dann muss a > b sein und eine solche Prüfung ist unnötig.

 

[sascha-sphw]

Eine Zuweisung wie in Zeile 11 ist auch nicht möglch.

boolean = false;

Und u in Zeile 6 sieht auch merkwürdig aus.

 

[Jw456]

In jedem else-Block gibt es ein Return.
test2.intarray.length == 0 ist aber zB ein Fall, der nicht mit einem Return beendet wird.

nein im letzen else if ist kein return desshalb die Meldung vom Compiler

else if (test2.intarray.length < test.intarray.length) {
        for (int i = 0; i < test2.intarray.length; i++) {
            if (test.intarray[i] == test2.intarray[i]) {
                boolean2 = true;
            } else {
                boolean2 = false;
                return 39;
            }
            return 2;
        }
        // hier müsste ein return sein
    }

 

[kneitzel]

Es sind zwei Punkte:
a) das angesprochene if / else if / else if
b) nur return in einer for schleife.

Beides ist für den Compiler nicht zu verstehen. Wobei a lediglich "riecht" - aber b ist schlicht falsch, denn im Schleifen-Körper wird immer ein return ausgeführt, d.h. der Code lässt sich vereinfachen:

Ein Block wie:

for (int i = 0; i < test2.intarray.length; i++) {
            if (test.intarray[i] == test2.intarray[i]) {
                boolean2 = true;
            } else {
                boolean2 = false;
                return 39;
            }
            return 2;
        }

Wird dann einfach zu:

if (0 < test2.intarray.length) {
            if (test.intarray[i] == test2.intarray[i]) {
                return 2
            } else {
                return 39;
            }
}

 

[thecain]

nein im letzen else if ist kein return desshalb die Meldung vom Compiler

So gesehen gibt es in keinem if ein return. Es ist ja immer im for-loop.

/Edit ah doch im mittleren hat es.

 

[Mart]

deine booleans machen bis jetzt auch noch wenig sinn da du sie nie nutzt du änderst sie und wirfst sie weg


dass ein return am ende verlangt wird liegt in deinem if else da du kein else {} hast könnte irgend ein fall eintreten wo man durch das if durchkommt zumindest sieht dien compiler das so, nur weil du logisch alles abgedeckt hast weis das der compiler nicht dass es schon alles abgedeckt ist, nur ein else am ende "deckt" alle alternativ fälle ab dh du brauchst den vergleich des letzten else if nicht

es kann nur noch als extra fall vorkommen dass test2 > test ist dh wenn du da hinkommst vergleichst du ansich true == true
es kann nur noch wahr raus kommen deswegen kannst du auch gleich else {} schreiben

 

[Mart]

du könntest zusätzlich das in eine public und private Variante aufteilen

in der public variante überprüfst du ob die arrays != null sind falls sie es sind wirfst du nen fehler oder sonst was
wenn die arrays nicht null sind dann kannst du in die private variante gehen und mit deinen for schleifen hantieren so trennst du die möglichen fehler von der logik und vermsicht nicht fehler behandlung mit berechnungen