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

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