Discussion :

[totot]

Bonjour,

J'ai une boucle for que je souhaiterais quitter quand je suis passer dans un de mes if mais je vois pas comment faire proprement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
for (Entry<Integer, Integer> mapEntry : map.entrySet()) {
if(...){
 
}else if (...){
 
}else if(...){
 
}
}

[plawyx]

break;

https://docs.oracle.com/javase/tutor...ts/branch.html

[totot]

Je chercher un truc plus propre que le break

[tchize_]

plus "propre"? En quoi le break est sale?

[thelvin]

Personnellement quand j'en arrive à des trucs qui ressemblent à ça je préfère un return, ça isole les codes les uns des autres et puis ça colle un nom à ce que je fais dans cette boucle.

Mais oui, on peut se demander d'où vient cette idée de "pas propre."

[totot]

Je veux si je passe dans le if, quitter la boucle car j'ai rempli une condition.
Mon problème c'est que je trouve pas très propre de mettre plein de break

[joel.drigo]

Tu ne peux pas sortir d'un forEach autrement que par un break, ou un return (Enfin, je te dirais bien qu'il y a aussi le System.exit() pour sortir de la boucle, mais c'est un peu radical...) si ta boucle est dans une méthode (on sort de la méthode, donc on sort de la boucle). Parce qu'il n'y a de toute manière pas de contexte de gestion de boucle (pas de moyen d'agir sur une condition de bouclage) et pas d'autre moyen de sortir que break (vu que c'est fait pour ça). Et je ne vois trop où est le problème (d'utiliser break dans ce cas).

Si le break te file des cauchemars (je me demande comment tu fais avec un switch pour te passer de break), avec un for, on pourrait mettre en place un boolean :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
boolean loop=true;
for(int i=0; loop & i<nb; i++) {
     if ( ... ) {
 
         loop=false;
 
    }
}

Avec une boucle sur itérateur, on pourrait "vider" l'itérateur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
while( iterator.hasNext() ) {
 
       iterator.next();
 
       if ( ... ) {
 
          while( iterator.hasNext() ) iterator.next();
 
      }
 
}

Mais autant mettre un break (ne serait-ce que pour éviter de passer du temps et consommer de la mémoire pour aller au boutl'itérateur). Et c'est moins lisible, plus compliqué...

Ou alors tu filtres avant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Optional<Entry<Integer, Integer>> opt = map.entrySet().stream().filter(e-> {
    if ( ... || ... || ... ) {
        return e;
    }
    return null;
} ).filter(Objects::nonNull).findFirst();
opt.ifPresent(e-> {
  if ( ... ) {
  }
  else if ( ... ) {
  }
  else if ( ... ) {
  }
 
});

On voit pas de break, mais c'est nettement plus compliqué... et on multiplie les tests... et la première boucle revient à tout parcourir (mais on ne réagit que sur le premier qui matche l'une des conditions, donc fonctionnellement c'est bon)

A voir si le problème ne peut pas se résoudre en changeant la façon de le traiter. Du genre, si on veut tester si les clefs sont valides

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Set<String> invalidKeys = map.keySet().stream().filter(k-> !isValid(k)).collect(Collectors.toSet());
if ( invalidKeys.isEmpty() ) {
   // ok
}
else {
  // ko - et on a la liste des clefs invalides au besoin
}

Je ne sais pas si elles seront propres ou sales, mais toute autre soluton sera plus allambiquées/compliquées, et moins performante.

[Gugelhupf]

Bonsoir totot,

Tu as créé le même sujet il y a moins d'une semaine (je t'ai même répondu).

[totot]

Si j'utilise un return dans chaque if. Il ne va pas continuer mon for si je passe dans un if et donc que je fait le return?

[tchize_]

le principe du return c'est comme le break, ça interrompt immédiatement le travail. Le return arrête le travaille sur la méthode, le break le travail sur la boucle.