Discussion :

[Djobird]

Bonjour.

Voila, j'ai une LinkedList que je parcours à l'aide d'un iterator. Ma list ne peut théoriquement pas être modifié durant un parcours, je ne devrais donc pas avoir de concurent exception. Néanmoins, l'application va évoluer, et on sait jamais ce qui peut se passer.

Je voudrais donc savoir comment je peux utiliser un iterator tout en étant sur de jamais lever une concurent exception ?
Et au passage, pourquoi cette exception est levée ? Je veux dire, je sais quand cette exception arrive, mais je ne comprend pas pourquoi elle a été implémentée ?

[adiGuba]

Salut,

Je voudrais donc savoir comment je peux utiliser un iterator tout en étant sur de jamais lever une concurent exception ?

L'exception peut être levée dans deux cas :

• Si tu modifies la liste depuis un autre thread. Mais dans ce cas il faut impérativement synchronisé le tout sous peine d'obtenir des problèmes bien plus grave :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  	List<Object> list = Collections.synchronizedList(new LinkedList<Object>());
   
  	// ...
   
  	synchronized (list) {
  		for (Object o : list) {
   
  		}
  	}

  Ce qui devrait résoudre le problème.
  
• A moins que tu ne modifies directement la liste pendant son parcours via un iterateur.
  
  La solution consiste tout simplement à ne pas modifier la liste pendant le parcours de l'iterateur (à moins d'utiliser les méthodes de l'itérateur).
  
  Bref lors d'un parcours via iterateur, tu ne devrais pas utiliser la référence de la collection que tu parcours, et surtout pas modifier son contenu...

Et au passage, pourquoi cette exception est levée ? Je veux dire, je sais quand cette exception arrive, mais je ne comprend pas pourquoi elle a été implémentée ?

C'est un cas typique de code "fail-fast". C'est à dire un code qui plante rapidement.

Lorsque tu modifies une liste pendant son parcours, tu peux générer un grand nombre de cas particulier qui peuvent dépendre de l'implémentation. Théoriquement si on voudrait faire cela il faudrait que l'iterateur vérifie à chaque fois les modifs qui ont été faites pour essayer de les prendre en compte, avec tous les cas particulier que cela représente :
Que faire lorsque l'élément courant est supprimé ? le suivant ? le premier ? le dernier ?
Que faire lorsqu'un élément est ajouté à la liste ? au début ? à la fin ? avant/après l'élément courant ?

Tout ceci peut vite s'avérer complexe à prendre en compte, sans garantie d'un fonctionnement optimal. En clair selon les conditions de la modification, l'itérateur pourra fonctionner normalement ou pas...


L'optique "fail-fast" consiste à générer une exception dès qu'une modification est détecté. Ainsi on va peut-être généré des exceptions sur des cas qui pourrait peut-être être récupéré, mais cela permet de mettre en avant un problème potentiel et d'éviter tout problème...



a++

[Djobird]

Mh d'accord, merci bien.