Exception safety - patterns for reliably rolling back object state

Question

I've been thinking about how to implement the various exception safety guarantee, especially the the strong guarantee, i.e. data is rolled back to it's original state when an exception occurs.

Consider the following, wonderfully contrived examples (C++11 code). Suppose there is a simple data structure storing some value

struct Data
{
  int value = 321;
};

and some function modify() operating on that value

void modify(Data& data, int newValue, bool throwExc = false)
{
  data.value = newValue;

  if(throwExc)
  {
    // some exception occurs, sentry will roll-back stuff
    throw std::exception();
  }
}

(one can see how contrived this is). Suppose we wanted to offer the strong exception-safety guarantee for modify(). In case of an exception, the value of Data::value is obviously not rolled back to its original value. One could naively go ahead and try the whole function, setting back stuff manually in appropriate catch block, which is enormously tedious and doesn't scale at all.

Another approach is to use some scoped, RAII helper - sort of like a sentry which knows what to temporarily save and restore in case of an error:

struct FakeSentry
{
  FakeSentry(Data& data) : data_(data), value_(data_.value)
  {
  }

  ~FakeSentry()
  {
    if(!accepted_)
    {
      // roll-back if accept() wasn't called
      data_.value = value_;
    }
  }

  void accept()
  {
    accepted_ = true;
  }

  Data& data_ ;
  int   value_;

  bool accepted_ = false;
};

The application is simple and require to only call accept() in case of modify() succeeding:

void modify(Data& data, int newValue, bool throwExc = false)
{
  FakeSentry sentry(data);
  data.value = newValue;

  if(throwExc)
  {
    // some exception occurs, sentry will roll-back stuff
    throw std::exception();
  }

  // prevent rollback
  sentry.accept();
}

This gets the job done but doesn't scale well either. There would need to be a sentry for each distinct user-defined type, knowing all the internals of said type.

My question now is: What other patterns, idioms or preferred courses of action come to mind when trying to implement strongly exception safe code?

Answer 1

In general it is called ScopeGuard idiom. It is not always possible to use temporary variable and swap to commit (though it is easy when acceptable) - sometime you need to modify existing structures.

Andrei Alexandrescu and Petru Marginean discuss it in details in following paper: "Generic: Change the Way You Write Exception-Safe Code — Forever".

---

There is Boost.ScopeExit library which allows to make guard code without coding auxiliary classes. Example from documentation:

void world::add_person(person const& a_person) {
    bool commit = false;

    persons_.push_back(a_person);           // (1) direct action
    // Following block is executed when the enclosing scope exits.
    BOOST_SCOPE_EXIT(&commit, &persons_) {
        if(!commit) persons_.pop_back();    // (2) rollback action
    } BOOST_SCOPE_EXIT_END

    // ...                                  // (3) other operations

    commit = true;                          // (4) disable rollback actions
}

---

D programming language has special construct in language for that purpose - scope(failure)

Transaction abc()
{
    Foo f;
    Bar b;

    f = dofoo();
    scope(failure) dofoo_undo(f);

    b = dobar();

    return Transaction(f, b);
}:

Andrei Alexandrescu shows advantages of that language construct in his talk: "Three Unlikely Successful Features of D"

---

I have made platform dependent implementation of scope(failure) feature which works on MSVC, GCC, Clag and Intel compilers. It is in library: stack_unwinding. In C++11 it allows to achieve syntax which is very close to D language. Here is Online DEMO:

int main()
{
    using namespace std;
    {
        cout << "success case:" << endl;
        scope(exit)
        {
            cout << "exit" << endl;
        };
        scope(success)
        {
            cout << "success" << endl;
        };
        scope(failure)
        {
            cout << "failure" << endl;
        };
    }
    cout << string(16,'_') << endl;
    try
    {
        cout << "failure case:" << endl;
        scope(exit)
        {
            cout << "exit" << endl;
        };
        scope(success)
        {
            cout << "success" << endl;
        };
        scope(failure)
        {
            cout << "failure" << endl;
        };
        throw 1;
    }
    catch(int){}
}

Output is:

success case:
success
exit
________________
failure case:
failure
exit

Answer 2

The usual approach is not to roll back in case of an exception, but to commit in case of no exception. That means, do the critical stuff first in a way that does not necessarily alter program state, and then commit with a series of non-throwing actions.

Your example would be done like follows then:

void modify(Data& data, int newValue, bool throwExc = false)
{ 
  //first try the critical part
  if(throwExc)
  {
    // some exception occurs, sentry will roll-back stuff
    throw std::exception();
  }

  //then non-throwing commit
  data.value = newValue;
}

Of course RAII plays a major role in exception safety, but it's not the only solution.
Another example for "try-and-commit" is the copy-swap-idiom:

X& operator=(X const& other) {
  X tmp(other);    //copy-construct, might throw
  tmp.swap(*this); //swap is a no-throw operation
}

As you can see, this sometimes comes at the cost of additional actions (e.g. if C's copy ctor allocates memory), but that's the price you have to pay some times for exceptionsafety.

Answer 3

I found this question when faced with the case at the end.

If you want to ensure the commit-or-rollback semantics without using copy-and-swap I would recommend providing proxies for all objects and using the proxies consistently.

The idea would be to hide the implementation details and limit the operations on the data to a sub-set that can be rolled back efficiently.

So the code using the data-structure would be something like this:

void modify(Data&data) {
   CoRProxy proxy(data);
   // Only modify data through proxy - DO NOT USE data
   ... foo(proxy);
   ...
   proxy.commit(); // If we don't reach this point data will be rolled back
}

struct Data {
  int value;
  MyBigDataStructure value2; // Expensive to copy
};

struct CoRProxy {
  int& value;
  const MyBigDataStructure& value2; // Read-only access

  void commit() {m_commit=true;}
  CoRProxy(data&d):value(d.value),value2(d.value2),
      m_commit(false),m_origValue(d.value){;}
  ~CoRProxy() {if (!m_commit) std::swap(m_origValue,value);}
private:
  bool m_commit;
  int m_origValue;
};

The main point is that the proxy restricts the interface to data to operations that the proxy can roll back, and (optionally) provides read-only access to the rest of the data. If we really want to ensure that there is no direct access to data we can send the proxy to a new function (or use a lambda).

A similar use-case is using a vector and rolling back push_back in case of failure.

template <class T> struct CoRVectorPushBack {
   void push_back(const T&t) {m_value.push_back(t);}
   void commit() {m_commit=true;}

   CoRVectorPushBack(std::vector<T>&data):
    m_value(data),m_origSize(data.size()),m_commit(false){;}

   ~CoRVectorPushBack() {if (!m_commit) value.resize(m_origSize);}

private:
   std::vector<T>&m_value;
   size_t m_origSize;
   bool m_commit;
};

The downside of this is the need for making a separate class for each operation. The upside is that the code using the proxies is straightforward and safe (we could even add if (m_commit) throw std::logic_error(); in push_back).