+1  A: 

Why not simply return, i.e.,

public void updateEvent() { 
    //object's update event 
    remove(this); 
    return;   
    //obviously unreachable 
    System.out.println("Should never reach here!");     }
jball
A: 

Why don't you just:

  • Maintain the objectList in the object that runs the loop
  • Don't let the GameObjects have access to the list (why should they?)
  • Have the updateEvent function return a boolean. If the return value is false, the parent object removes that object from the list of events. The return statement also serves to terminate execution of the event function.
Reinderien
I am maintaining the object list in the object that runs the loop, and GameObjects don't have direct access to it.You third point sounds great. I think I'll do that and use the iterator's remove method to instantly remove them. Cleaner than storing them all in a list and modifying them at the end.
Kyle_Solo
A: 

@jball's answer is great-- +1.

Another method I've used that works well and might be slightly cleaner is to have your updateEvent() method return a boolean. Whenever a True is returned from updateEvent, you remove() the object.

This allows your event loop to have more control over how the loop itself is executed and removes a little bit of unnecessary binding between your classes.

Bill K
+1  A: 

I agree that the exception approach is the best way to implement the remove method according to your specification.

However, maybe you should reconsider the specification. I would leave the decision of when updateEvent terminates to the implementor. Termination with the remove() call is confusing, and requires usage of exceptions for flow control. I believe that the call to remove() should only change the flag state. And I see no real problem with looping over all objects, checking the removed flag for each of them.

Eyal Schneider
I'm thinking the same thing. It's the requirement to immediately stop execution that smells, not using exceptions to accomplish that. Besides, even with exceptions you're still at the mercy of your clients. An updateEvent implementation could easily catch the exception and not rethrow it, allowing them to continue executing if they choose.
Mark Peters