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?

4 Answers 4


There is a cleaner way and it is to use immutable/persistent data structures. This is an idea from functional programming but there's really no reason that you couldn't do it in an object-oriented paradigm also.

You construct the data in such a way that it is never deleted or mutated. Updates create a new structure without changing the data of the old structure. If an update goes awry, you revert to the previous version. If it is successful you can discard the previous version depending on your needs.


  • +1. This is the approach I use, and it's probably saved me countless hours too.
    – Neil
    Commented Apr 30, 2013 at 13:09
  • I wanted to do it this way. but I have many children being created at the bottome level of the tree. adding one means replacing it's parent, and it's parent's parent etc etc. it would grow CPU intensive to make some changes this way.
    – dsollen
    Commented Apr 30, 2013 at 18:33
  • @dsollen in that case, perhaps you could aggregate a rollback lambda using the command pattern?
    – Victor
    Commented May 1, 2013 at 12:39
  • You were right ultimately. The mutable structure just ended up with too many 'smells', I gave up and made it all immutable; but with a model that still automatically keeps track of children/parent relationships via hashMaps in a generic manner (so I can still add a child to a parent quickly, because the parent doesn't know the child directly; it only knows it's children via a call to the model. Once I did this I can almost do what you suggested for rollback. I need to actually add things to my model as I go to keep getChildren working. I can record every add/remove and revert if needed.
    – dsollen
    Commented May 16, 2013 at 14:31
  • @dsollen cheers, glad it appears to be working out for you in the end.
    – Victor
    Commented May 18, 2013 at 12:50

If you can afford the memory, you could take a snapshot before making any changes. If everything goes fine, delete the snapshot. If anythong goes wrong, drop the new version and just revert to the snapshot.

If this is too expensive, you could first compute which parts could possibly be affected (DFS or something) and only take a snapshot of those parts.


There are two design patterns available for Undo / Redo operations that are worth looking into. The first is the Command Design Pattern: -


And the 2nd, is the Memento design pattern: -


Hope that helps.


Firstly, do you really need to revert the state? When something has just gone wrong in your program, does it makes sense to try to stay up rather than crash and burn? It can be a lot of work to try and make your program resilient to that sort of thing, and you have to gauge whether you'd be better off spending that time fixing the bugs causing the exceptions.

I suggest doing something related to the technique used by a database. Databases keep a log of all the changes that are made so that they can back through the log and undo all the changes. So I'd have code that looks like

transaction = TreeTransaction()
    foo.add(bar, transaction);
    bar.add(goat, transaction);

Depending on your language there is usually some ways to improve the pattern. The idea is that all changes are made within the context of a transaction. When an unexpected error occours, the rollback method puts everything back the way it was. Commit can make changes official, if that makes sense.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.