Je me demande pourquoi je n'ai pas besoin de retourner une valeur dans ce
Méthode privée CODE>? P>
private String testLoop() {
while(true) {
if(false == true) {
break;
}
}
return null;
}
5 Réponses :
Vous appelez la méthode TestLoop et ne nécessitant pas une valeur de retour .... Si vous l'avez écrit comme ceci, la méthode privée devra renvoyer quelque chose.
Édité pour montrer une langue correcte, merci@ David99World
VOTRE LOOP PENDANT (TRUE) {} CODE> Ne finirez jamais SE SO COMPILER ne s'attend pas à une déclaration de retour.Si le compilateur trouve la boucle finira alors il s'agit d'une déclaration de retour.Vous peut le tester manuellement.Rissez avec
int i = 1; tandis que (i <0) code> Cela donnera une erreur de compilation et un compilateur vous demandera de vous recître p>
Pas le meilleur exemple, car le corps de la boucle est inaccessible ..
@Franzebner désolé je ne t'ai pas eu
@ Franzebner's Point est que le corps de (1 <0) sera jamais i> être exécuté, il peut donc ne pas être le meilleur exemple non plus.
@Joshuataylor ohh maintenant j'ai eu, c'était juste un exemple.well je vais le modifier bientôt
@Joshuataylor s'il vous plaît voir la réponse mise à jour
@Franzebner merci pour votre commentaire, maintenant j'ai mis à jour s'il vous plaît voir
@javabeginner mieux!
private String testLoop() { while(true) { } //infinite loop } Above method never return since there is infinite loop there. So it is not expecting return Or it will never reach return.
+1 Ajouter une pause; À l'intérieur de la boucle et le compilateur jurera!
tandis que (vrai) {} ne laisse pas exécuter une autre instruction, vous écrivez
private String testLoop() { while(true) { } //any code at this point is not reachable since it wont come out of while loop. So return statement just like any java code wont be reachable. }
La méthode n'a pas vraiment de point de retour pendant la compilation, ce qui signifie que lorsqu'il est compilé, il ne vient jamais une heure dans laquelle il "cherche" un retour .. P> Ce n'est pas une bonne pratique bien sûr et des cycles vides, en particulier ceux avec true code> de la condition doivent apparaître comme une erreur dans votre IDE. p> p>
Que pensez-vous être illégal à ce sujet?
Fait intéressant dès que vous mettez une pause
code> à l'intérieur de la boucle Java se contrarie à nouveau. Le compilateur Java est plus intelligent que ce que j'avais imaginé
Le
si (faux == true) code> est explicitement exclu de la vérification du contrôle de flux par la spécification de langue pour permettre des constructions telles que
si (débogage) ... code> où
debug code> est un
final statique Boolean code>, c'est-à-dire une constante de temps de compilation. Donc, ce
si (...) pause; code> est traité comme "pourrait arriver ou non" même si l'expression de la condition est une constante de la compilation. Vous pouvez donc changer la valeur de la constante code> de débogage code> sans casser le code.