BackupController is designed as a stack. We register changes which we need to backup and later restore on the stack, saving state whenever something is added. Then, when we call BackupController.pop_all(), we restore the state in the reverse order that it was added.

The question to be explored here is what to do in the error case: When we restore the state and the element that we are popping does not succeed, do we want to fail at that point or do we want to continue to try restoring things further down the stack? Continuing to restore is not necessarily safe (if the additional restores would be affected by the failed one) but the system may be closer to the original if we do everything that we can.

The RestorableFile API which predates warns if it fails but does not error out.

Some options to evaluate:

• Always continue similar to how RestorableFIle works.
• As a developer, evaluate the safety of continuing after a failed restore for each type of RestorableChange. If it is reasonably safe, use the BackupController framework. If it is not, do that backup and restore ad hoc.
• Add an attribute to each RestorableChange. If the attribute is set, then stop if that Change fails to restore. Otherwise emit a warning and continue.