Using scope guards as code contracts

Question

So we're investigating the use of scope guards or some similar mechanism to ensure incoming/outgoing object validity and/or internal state invariance, similar to C# Code Contracts.

In the specific case where an unexpected condition/exception arises in the middle of normal processing that causes some objects to be left in an inconsistent state, what mechanism could/should we use to side-step the fact that the scope guard is going to complain when we jump out of the function?

Here's some sample pseudocode to illustrate my point:

struct IObjectValidator;

struct ObjectValidatorScopeGuard
{
  ObjectValidatorScopeGuard(IObjectValidator * pObj) 
    : m_ptr(pObj) 
  {
    Assert(!m_ptr || m_ptr->isValid());
  }

  ~ObjectValidatorScopeGuard()
  {
    Assert(!m_ptr || m_ptr->isValid());
  }
  private:
    IObjectValidtor * m_ptr;
};


int SomeComponent::CriticalMethod(const ThingA& in, ThingB& inout, ThingC * out)
{
  ObjectValidatorScopeGuard sg1(static_cast<IObjectValidator *>(&in));   
  ObjectValidatorScopeGuard sg2(static_cast<IObjectValidator *>(&inout));
  ObjectValidatorScopeGuard sg3(static_cast<IObjectValidator *>(out));

  // create out
  try
  {
     out = new ThingC();
     out->mergeFrom(inout, out); // (1)
  }
  catch (const EverythingHasGoneHorriblyWrongException& ex)
  {
     // (2) out and inout not guaranteed valid here..
  }
  return 0;
}

So if something goes wrong in (1) that causes 'out' or 'inout' to be in a bad state at point (2), the scope guards sg2/sg3 are going to throw exceptions... and those exceptions could mask the true cause.

Is there any pattern/convention to work with this scenario? Are we missing something obvious?

Answer 1

In case of an exception in the block of code guarded by your object validator, the C++ runtime will call terminate. You cannot throw exceptions, as your destructor does, while other exception is being handled. Therefore you should not throw exceptions from destructor (details here). Instead of throwing an exception you should use assert or log the error.

Still better than checking invariants is to guarantee that they will never be broken. That is called exception safety. Basic exception safety (preserving the invariants) is usually easy to achieve just by clever reordering of statements and using RAII.

Example of exception safety techniques:

class String {
  char *data;

  char *copyData(char const *data) {
    size_t length = strelen(rhs->data);
    char *copy = new char[length];
    memcpy(data, rhs->data, length);
    return data;
  }

public:
  ~String() { delete[] data; }

  // Never throws
  void swap(String &rhs) { std::swap(data, rhs->data); }

  // Constructor, Copy constructor, etc.
};

// No exception safety! Unusable!
String &String::operator = (String const &rhs) {
  if(&rhs == this) return *this;

  delete[] data;
  data = copyData(rhs->data); // May throw
}

// Weak exception safety
String &String::operator = (String const &rhs) {
  if(&rhs == this) return *this;

  delete[] data;
  data = 0; // Enforce valid state
  data = copyData(rhs->data); // May throw
}

// Strong safety 1 - Copy&Swap with explicit copy
String &String::operator = (String const &rhs) {
  String copy(rhs);// This may throw
  swap(copy);// Non-throwing member swap
  return *this;
}

// Strong safety 2 - Copy&Swap with pass by value
String &String::operator = (String rhs) {
  swap(rhs);// Non-throwing member swap
  return *this;
}

Answer 2

Interesting to put an assertion in a scope guard. It's not the usual use case, but not a bad idea to improve their coverage.

Just be aware that you can't throw another exception when you're already handling one. So a problem with in, out, or inout can't be delegated somewhere else, you need to take care of it immediately.

If all you want is to print a debug message when the assertion is violated (expected behavior for Assert), then simply print the message and continue on your way… don't mess with exceptions at all.

If Assert should tie into a greater exception handling mechanism, then exception objects should have structure to accommodate whatever Assert actually produces. But getting that state into the appropriate exception object is nontrivial. Assert is called during stack unwinding, before the exception has been handled, before it's accessible by rethrow i.e. (try { throw; } catch ( structured_e & ) {}). You would need a thread-local variable to store the current structured exception, initialized by structured_e::structured_e().

Long story short, my advice is to provide a separate WeakAssert for use in destructors and scope guards which doesn't throw an exception.

See also Herb Sutter's article on why not to be clever when combining exceptions and destructors.