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?
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
5
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: –
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.
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.