Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

4 Answers

up vote 2 down vote accepted

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.

https://en.wikipedia.org/wiki/Persistent_data_structure

share|improve this answer
    
+1. This is the approach I use, and it's probably saved me countless hours too. –  Neil Apr 30 '13 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 Apr 30 '13 at 18:33
    
@dsollen in that case, perhaps you could aggregate a rollback lambda using the command pattern? –  Victor May 1 '13 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 May 16 '13 at 14:31
    
@dsollen cheers, glad it appears to be working out for you in the end. –  Victor May 18 '13 at 12:50
add comment

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.

share|improve this answer
add comment

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

http://en.wikipedia.org/wiki/Command_pattern

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

http://en.wikipedia.org/wiki/Memento_pattern

Hope that helps.

share|improve this answer
add comment

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()
try
{
    foo.add(bar, transaction);
    bar.add(goat, transaction);
    transaction.commit();
}
catch(...)
{
    transaction.rollback();
}

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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