So I have a generic framework with a concept of children and parent objects, the objects don't have to be the same type, and I can add or remove any of them. Adding calls add on all the children, and informs the parents, inverse for remove.
the concept of Parent is generic enough that there can be a loop across classes. A may be a parent of B which is a parent of C which is a parent of A. This still works, since I mark an object as added or removed as the first step in the abstract class; so even if a circular dependency calls Add a second time on the same object the second time through the add will return without doing anything (because the added boolean is already set) and we halt our recursion.
If some unexpected exception occurs I want to revert my state back to what it was before the exception occurs. I was doing this with exception handling, if I catch a run time connection I remove objects I added and update parents before throwing the exception. This is where my logic can fail. As of now I 'revert' the AddObject method by calling removeObject and vice versa. If my state somehow ended up in a truly bizarre state I could keep throwing exceptions, add throws and calls remove, remove throws and calls add, etc etc. I think this still has a chance for infinite recursion; though admittedly something would already have to be pretty messed up in my state for it to happen.
Is there a cleaner way to do my rollback logic to avoid this potential? At a point like this what should I say my state should be once I recover anyways?