Question

Modifying a set over iteration sometimes creates an exception, and other times it doesn’t, why?

concurrent modification exception

       Set<Integer> j = new HashSet<Integer>();
       j.add(23);
       j.add(45);
       j.add(64);
       int c=0;
       for(Integer k: j)
       {
         if(c++==0)
         {
             j.remove(45);
         }
       }
      System.out.println(j); // concurrent modification exception

     <hr>

 //works without exception
     Set<Integer> j = new HashSet<Integer>();
       j.add(23);
       j.add(45);
       j.add(64);
       int c=0;
    for(Integer k: j)
    {
       if(k==45)
       {
           j.remove(45);
       }
    }
    System.out.println(j);//works without exception

Answer 1

From the JavaDocs for HashSet:

The iterators returned by this class’s iterator method are fail-fast: if the set is modified at any time after the iterator is created, in any way except through the iterator’s own remove method, the Iterator throws a ConcurrentModificationException. Thus, in the face of concurrent modification, the iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future.

Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs.

(The highlighting is mine.)