Failure handling with destructors vs. catch (...) { fix(); throw; }

Question

Let's say I'm doing something that requires cleanup when an exception is thrown.

For example, say I'm creating a dynamic array, and I need to construct objects, but their constructors may throw an exception:

size_t const n = 100;
T *const p = static_cast<T *>(operator new(sizeof(T) * n));
size_t i;
for (i = 0; i < n; ++i)
    new (&p[i]) T(1, 2, 3);      // Not exception-safe if T::T(T const &) throws!

I can fix it either via catch (...) { ...; throw; }:

size_t const n = 100;
T *const p = static_cast<T *>(operator new(sizeof(T) * n));
size_t i;
try
{
    for (i = 0; i < n; ++i)
        new (&p[i]) T(1, 2, 3);
}
catch (...)
{
    while (i > 0)
        p[--i].~T();
    operator delete(p);
    throw;
}

or via a scoped destructor:

size_t n = 100;
struct Guard
{
    T *p;
    size_t i;
    Guard(size_t n) : i(), p(static_cast<T *>(operator new(sizeof(T) * n))) { }
    ~Guard()
    {
        while (i > 0)
            p[--i].~T();
        operator delete(p);
    }
} guard(n);

for (guard.i = 0; guard.i < n; ++guard.i)
    new (&guard.p[guard.i]) T(1, 2, 3);

guard.i = 0;     // Successful... "commit" the changes
guard.p = NULL;  // or whatever is necessary to commit the changes

Which technique should I prefer to use when, and why?

(Note: This example is only meant to show the difference between two techniques. I know it's not perfect code, so please do not focus on this particular example. It's just for illustration.)

Answer 1

The solution with destructor is better than the explicit try/catch:

• it is reusable, if you will need to do similar initialisation in another function, you can just reuse the same guard class
• it is easier to maintain - let's say that in some situation your function needs to return with failure but no exception is thrown. With the guard class it is handled more or less automatically
• it is cleaner, since the code is more modular

Answer 2

In general, I would say it is a matter of scaling and safety.

The problem with try/catch is two-fold:

• safety issue: any early return that ignores the catch (somehow) fails to cleanup
• scaling issue: nested try/catch blocks make a mess of the code
• scoping issue: to be accessible in the catch the variable must be defined before the try and thus supports default-construction/nullability; it can be painful

Instead, Deferred Statements and Guards do not create unnecessary blocks/scopes and thus no indentation, and read linearly.

Example:

char buffer1[sizeof(T)];
try {
    new (buffer1) T(original);

    char buffer2[sizeof(T)];
    try {
        new (buffer2) T(original);

        // stuff here

    } catch(...) {
        reinterpret_cast<T*>(buffer2)->~T();
        throw;
    }

} catch(...) {
    reinterpret_cast<T*>(buffer1)->~T();
    throw;
}

Compared to:

char buffer1[sizeof(T)];
new (buffer1) T(original);
Defer const defer1{[&buffer1]() { reinterpret_cast<T*>(buffer1)->~T(); } };

char buffer2[sizeof(T)];
new (buffer2) T(original);
Defer const defer1{[&buffer2]() { reinterpret_cast<T*>(buffer2)->~T(); } };

// stuff here

I would note that it seems a good idea to generalize those:

class Guard {
public:
    explicit Guard(std::function<void()> f): _function(std::move(f)) {}

    Guard(Guard&&) = delete;
    Guard& operator=(Guard&&) = delete;

    Guard(Guard const&) = delete;
    Guard& operator=(Guard const&) = delete;

    ~Guard() {
        if (not _function) { return; }
        try { _function(); } catch(...) {}
    }

    void cancel() { _function = std::function<void()>{}; }

private:
    std::function<void()> _function;
}; // class Guard

class Defer {
public:
    explicit Defer(std::function<void()> f): _guard(std::move(f)) {}
private:
    Guard _guard;
}; // class Defer