Ausgabe
Angesichts dieses Codeausschnitts, der eine Klasse TestClassmit ihrer Methode enthält loopTest(), ist das unser Hauptaugenmerk:
public class TestClass{
public void loopTest(){
int x = 0;
loop: for (int i = 1; i < 5; i++){
for (int j = 1; j < 5; j++){
System.out.println(i);
if (x == 0) { continue loop; }
System.out.println(j);
}
}
}
}
Das Ausführen dieses Codes in IntelliJ IDEA gibt keine Kompilierungsfehler zurück, gibt jedoch erfolgreich eine Ausgabe zurück. Meine Frage wäre: Warum ist dies keine unerreichbare Aussage?
Ausführen der Schleife nach dem Entfernen der if (x == 0)Anweisung (aber continue loop;wie unten gezeigt:
loop: for (int i = 1; i < 5; i++){
for (int j = 1; j < 5; j++){
System.out.println(i);
continue loop;
System.out.println(j);
}
}
(…) würde einen solchen Fehler zurückgeben, weil der letzte soutnie gedruckt würde. Warum passiert das nicht auch im ersten Fall? Ich bin mir ziemlich sicher, dass dies kein Laufzeitproblem ist, da der Compiler definitiv sieht, dass die ganze Zahl xam Anfang der Methode initialisiert wird, aber die Schleife nie die zweite Anweisung erreicht.
Lösung
Siehe Antwort von rzwitserloot – es liegt eigentlich daran, dass Java ifAnweisungen absichtlich von einer tieferen Analyse ausschließt, da es sich um ein nützliches Feature handelt.
Als Referenz die Antwort, die auf falschen Annahmen basiert:
Dies liegt daran, dass der Compiler Grenzen dafür hat, wie tief die Analyse geht.
if (false) System.out.println("never");
ist zum Beispiel in Ordnung, weil diese Bedingungen nicht überprüft werden. Der Compiler geht davon aus, dass Bedingungen wahr sein können, auch wenn dies in der Praxis unmöglich ist.
Code nach einem unbedingten continue, return, breakist bekanntermaßen ohne weitere Analyse nicht erreichbar.
Neuere Sprachen können diese Art von Analyse durchführen, und ich denke, Tools wie SonarLint könnten das auch finden. Sogar Java zur Laufzeit optimiert diesen Code möglicherweise weg, aber ich denke, das Alter / der Stand der statischen Codeanalyse zum Zeitpunkt der Java-Formalisierung ist für dieses Verhalten verantwortlich.
Der if (false)Trick ist auch eine ziemlich übliche Methode, um Code zum schnellen Testen zu deaktivieren, also könnte das Hinzufügen dieses jetzt eine Menge Code beschädigen, und ich denke, das macht es unwahrscheinlich, dass es als Sprach-/Compiler-Funktion hinzugefügt wird, obwohl es heutzutage durchaus machbar ist.
Beantwortet von – zapl
Antwort geprüft von – Clifford M. (FixError Volunteer)
