[java] ConcurrentModificationException

[albymotard]

Ragazzi ho un problema con questa eccezione....ho guardato anche qua e la ma non ho ancora capito bene cosa voglia dire.
Se non ho capito male l'eccezione ConcurrentModificationException mi vieni fuori (vi spiego cosa faccio nel programma) quando in un metodo di una classe eseguo un ciclo for.each di un vettore e ogni oggetto del vettore lo passo ad un metodo di UN ALTRA CLASSE per fare dei controlli e nel caso eliminare l'oggetto.
Ringrazio in anticipo

[valia]

leggere le API pleasee!!!!
Allora, il ciclo for enanched è uno zuccherino sintattico in quanto al tuo posto viene istanziato un iteratore che scorre la tua collection, restituendoti via via l'elemento corrente.
Non è possibile quindi modificare la collection all'interno di un ciclo di questo tipo (si potrebbero perdere riferimenti dell'iteratore) ed ecco l'eccezione che vedi tu viene fuori.
Purtroppo quando bisogna fare cose di questo tipo (eventualmente eliminare un elmento dalla lista) bisogna usare una collection di appoggio
In pratica

1. scorri la collection di base (collA) elemento per elemento
2. controlli che collA(i) sia da eliminare o meno: se è da mantenere, mettilo in una nuova collection (collB)
3. collA = collB

in modo da bypassare il problema

[Mr.Bloom]

Oppure puoi usare l'iteratore esplicitamente, e rimuovere gli elementi tramite quest'ultimo.
Nel qual caso l'eccezione non viene sollevata. Ad esempio :

Collection<String> c = new Vector<String>();
for (Iterator<String> itr = c.iterator(); itr.hasNext(); ) {

    String s = itr.next(); 
    if( condizione(s) ) 
             itr.remove(); 

}

[Mr.Bloom]

Nel tuo caso albymotard, puoi passare l'iteratore come argomento al metodo che fa i controlli oppure far si che il metodo che fa i controlli ritorni un boolean che ti dice se l'elemento è da cancellare o no e agire di conseguenza nel metodo dove c'è il ciclo for.

[valia]

uhmm se proprio vuoi fare in un unico ciclo non usare iteratori, usa gli indici...non so, gli modifico in corsa gli iteratori e i riferimenti, mi può andare bene come mi può andare male, ma non amo molto mescolare cose che logicamente vanno divise.
se a me interessa eliminarli dal punto di vista di spazio non cambia molto perché la prima collection non sarà più riferita ed eliminata appena possibile assieme agli elementi che volevo eliminare

[albymotard]

Dovrei aver capito...quindi, per quanto riguarda l'eccezione sollevata, il problema si pone quando vado a modificare una collezione in un altra classe rispetto a dove viene chiamata giusto?? Cioè se modifissi la collezione nella stessa classe dove ho il metodo non avrei problemi???

[valia]

prova, ma devi considerare che logicamente non è corretto modificare mentre iteri.
A tal proposito guarda qui

[Mr.Bloom]

no non e' questione di classe. L'eccezione viene sollevata se fai le seguenti operazioni in sequenza:

1) crei un iteratore itr
2) modifichi la collezione in un modo diverso da itr.remove()
3) chiami itr.next() // nota che il ciclo for( String l : collection) e' equivalente a chiamare itr.next() ad ogni iterazione, e' solo un modo piu pulito per scrivere

for (Iterator<String> itr = c.iterator(); itr.hasNext(); ) {
         itr.next(); 
}

il problema e' che stai modificando la collezione tra il momento in cui l'iteratore e' stato creato ed il momento in cui chiami itr.next(), rompendo il contratto che vuole che la collezione non venga modificata da quando crei l'iteratore all'ultima volta che lo usi.

ad esempio il seguente codice non solleva eccezioni, perche l'iteratore esci dal ciclo e non usi piu l'iteratore, quindi non rompi il contratto.

Collection<String> c = new Vector<String>();
for( String s : c) {
    if(s.equals("da cancellare")){
             c.remove(s);
             break;
    }
}

[valia]

Mr Bloom hai fatto bene a riportare il comportamento corretto.
Il mio usare la struttura d'appoggio viene dalla volontà di separare logicamente l'operazione di controllo da quella di remove, cosa che in diverse occasioni mi ha evitato qualche mal di testa. E' una linea guida dettata dall'esperienza più che altro