Eindoofus
asked on
Why is the following code resulting in a java.lang.IndexOutOfBoundsException error?
Why is the following code resulting in a java.lang.IndexOutOfBounds Exception error?
I believe it may have started when I go the removal part of the code working? If I can remove while looping through an ArrayList then how am I supposed to remove without breaking out of the loop?
private void updateContent() throws InvalidDataException {
// Here you "move" each of your entities, and then instruct them to "update" themselves.
int index = 0;
while(!(entities.isEmpty())){
if(index == entities.size()){
index = 0;
}
Entity item = entities.get(index);
if (item.isDestroyed()){
ViewManager.getInstance().removeItem(entities.get(index).getIdentifier());
entities.remove(index);
//INSTRUCT THE ENTITY TO PERFORM IT'S DESTROYED BEHAVIOR item.Destroyed()
} else {
item.update(1);
ConsoleItem ci = new ConsoleItemImpl(item.getIdentifier(), item.getLocation(), ColorStringConverter.getInstance().StringToColor(item.getSide()), item.getAngle(), item.getShape(), item.toString(), item.isDestroyed(), item.isDamaged());
ViewManager.getInstance().updateItem(ci);
}
item.updateActivity();
item.update(1);
index++;
}
// updateInfo call
ViewManager.getInstance().updateInfo(summary());
}
I believe it may have started when I go the removal part of the code working? If I can remove while looping through an ArrayList then how am I supposed to remove without breaking out of the loop?
Put exception.printStackTrace( ) - you'll know the exact line where it throws this execption
ASKER
The following code fixes is and I don't see an Exception outputted. Why is that?
private void updateContent() throws InvalidDataException {
try{
// Here you "move" each of your entities, and then instruct them to "update" themselves.
int index = 0;
while(!(entities.isEmpty())){
if(index == entities.size()){
index = 0;
}
Entity item = entities.get(index);
if (item.isDestroyed()){
ViewManager.getInstance().removeItem(entities.get(index).getIdentifier());
entities.remove(index);
//INSTRUCT THE ENTITY TO PERFORM IT'S DESTROYED BEHAVIOR item.Destroyed()
} else {
item.update(1);
ConsoleItem ci = new ConsoleItemImpl(item.getIdentifier(), item.getLocation(), ColorStringConverter.getInstance().StringToColor(item.getSide()), item.getAngle(), item.getShape(), item.toString(), item.isDestroyed(), item.isDamaged());
ViewManager.getInstance().updateItem(ci);
}
item.updateActivity();
item.update(1);
index++;
}
// updateInfo call
ViewManager.getInstance().updateInfo(summary());
} catch(Exception e) {
e.printStackTrace();
}
It you think you know where it's throwing the exception, then print information about that line before you get there. Consider if it's the removeItem() line.
System.out.println ( getIdentifier() );
System.out.println ( entities.get(index).getIde ntifier()) ;
and so forth. You are looking for something that doesn't make any sense.
System.out.println ( getIdentifier() );
System.out.println ( entities.get(index).getIde
and so forth. You are looking for something that doesn't make any sense.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>The following code fixes is and I don't see an Exception outputted.
So you mean that you fixed it?
So you mean that you fixed it?
I don't think it's fixed in that example. It looks like exception happens only if the last element in the list is "destroyed", which could be quite random.
ASKER
@stachenov, is there any way that I can fix this?
I have already posted possible fix above. It basically amounts to that you shouldn't increase the index if you remove an item from the list (since index is already points to the next element after removal).
Of course, it only fixes a possible bug in the visible code. It is still possible that there are other exceptions deep down the stack in some of the functions called. You'll need a stack trace to fix that if it happens.
Of course, it only fixes a possible bug in the visible code. It is still possible that there are other exceptions deep down the stack in some of the functions called. You'll need a stack trace to fix that if it happens.