ConcurrentModificationException

[Anshul Kapoor]

The code shown here gives ConcurrentModificationException . The reason for this exception is that we are modifying the list while the iterator is Iterating it . I was asked to Fix this Exception by only putting code in the FIXME portion of the code . But I am unable to provide a solution . Kindly suggest .

import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
public class Test {
	public static void main(String[] args) {
	      final List<String> list = new ArrayList() {{ add("Hello"); }};
	      final Iterator<String> iterator = list.iterator();
	      System.out.println(iterator.next());
	      list.add("World");
	      //FIXME: insert some code here
	      //FIXME: ends here
	      System.out.println(iterator.next());
	}
}

[Lanny Gilbert]

Any reason you can't build the list first, then create the iterator and call the next() method on the iterator??

Or are there project requirements that you must implement which require you to create the iterator, then add new list elements.

[Paul Clapham]

Since the exception is thrown at line 9, it's impossible to change that no matter what code you add after line 9.

Edit: Looks like that's wrong. The exception is thrown at line 12, right? I agree with Lanny that (paraphrasing) this is a bad way to do things and you should do it some other way. But actually this is one of those interview questions which bears no relationship to good code in any way, right?

Assuming that, then yes, there's a perfectly simple line of code which can be inserted to make the exception go away. Just remember that in real life your goal wouldn't be to make the exception go away, it would be to dump that bad code.

[Rob Spoor]

The only way to prevent a ConcurrentModificationException on line 12 is to make sure that the iterator created on line 8 will no longer move forward. In other words, the iterator on line 8 and the iterator on line 12 cannot be the same anymore.

[Stephan van Hulst]

Hmm, this is only theoretically, but I think it might be possible to fool the iterator by making Integer.MAX_VALUE adds and removes to the list in between, overflowing the modification counter and setting it back to the number it was before the first add was called. It would only work if the list didn't check for overflow.

[Paul Clapham]

Going to the opposite end of the complexity scale, my suggestion for a line to insert to prevent an exception from being thrown at line 12 would be

System.exit(22);

[Mike Simmons]

Considering the iterator is final, Rob's suggestion seems problematic. I like Stephan's suggestion, though I'm not sure if it will work. Meanwhile, here's my hamfisted approach:

    try {
      Field f = Class.forName("java.util.AbstractList").getDeclaredField("modCount");
      f.setAccessible(true);
      f.set(list, 1);
    }
    catch (Exception e) {
      e.printStackTrace();
    }

Although we could also prevent the exception with a few much simpler techniques:

Thread.sleep(Long.MAX_VALUE);

or

System.exit(0);

[Paul Clapham]

Mike Simmons wrote:Considering the iterator is final, Rob's suggestion seems problematic.

I think that Rob's idea was my idea, too. Didn't notice that "final". Okay, I will solve that by having line 12 be in a place where the iterator isn't final after I insert my code.

[Campbell Ritchie]

The List is declared as final too. Otherwise it would have been so easy to reassign the Iterator.

[Matthew Brown]

How about inserting the following:

}

private void dummy(Iterator iterator) {

[Mike Simmons]

Nice!

[Stephan van Hulst]

Way to think outside the box block

[Paul Clapham]

That was my idea too, but I would have ended the "main" method with a call to your "dummy" method. But obviously that isn't necessary for the question as stated, so your idea is better than mine.

[Rob Spoor]

Stephan van Hulst wrote:Hmm, this is only theoretically, but I think it might be possible to fool the iterator by making Integer.MAX_VALUE adds and removes to the list in between, overflowing the modification counter and setting it back to the number it was before the first add was called. It would only work if the list didn't check for overflow.

Actually, if you make not Integer.MAX_VALUE but 2^32 modifications, it's not theoretical - I tried that once, and you will indeed fool the mod count.

[Stephan van Hulst]

Oh, I meant Integer.MAX_VALUE adds, and Integer.MAX_VALUE removes, which will amount to 2^32 -2 modifications, and then you need one more modification (possibly delete the original offending element) to end up on the previous count.

Hmm, I'm gonna try this one out.

[Rob Spoor]

Stephan van Hulst wrote:Oh, I meant Integer.MAX_VALUE adds, and Integer.MAX_VALUE removes, which will amount to 2^32 -2 modifications

2^32 - 1, not - 2.

[Stephan van Hulst]

public static void main(String... args) {
  long a = 2L * Integer.MAX_VALUE;
  long b = (long) Math.pow(2, 32) -2;
  System.out.println(a == b);
}

[Rob Spoor]

You're right, I was mistaking the first Integer.MAX_VALUE with Integer.MIN_VALUE.