Обработка сбоев деструкторами против catch (...) { fix(); бросить; }

Question

Допустим, я делаю что-то, что требует очистки, когда выдается исключение.

Например, скажем, я создаю динамический массив, и мне нужно создавать объекты, но их конструкторы могут выдавать исключение:

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!

Я могу исправить это либо через 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;
}

или через ограниченный деструктор:

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

Какую технику я предпочитаю использовать, когда и почему?

(Примечание: этот пример предназначен только для того, чтобы показать разницу между двумя методами. Я знаю, что это не идеальный код, поэтому, пожалуйста , не сосредотачивайтесь на этом конкретном примере. Он только для иллюстрации.)

Answer 1

Решение с деструктором лучше явного try/catch:

• его можно использовать повторно, если вам потребуется выполнить аналогичную инициализацию в другой функции, вы можете просто повторно использовать тот же класс защиты
• его легче поддерживать - скажем, что в некоторых ситуациях ваша функция должна возвращаться с ошибкой, но исключение не выдается. С классом охраны это обрабатывается более или менее автоматически
• это чище, так как код более модульный

Answer 2

В целом, я бы сказал, это вопрос масштабирования и безопасности.

Проблема с try/catch является двойным:

• проблема безопасности: любое раннее возвращение, которое игнорирует catch (каким-то образом) не удается очистить
• проблема масштабирования: вложенная try/catch блоки делают беспорядок в коде
• обзорная проблема: быть доступной в catch переменная должна быть определена до try и, таким образом, поддерживает default-construction / nullability; это может быть больно

Вместо этого отложенные операторы и охранники не создают ненужных блоков / областей и, таким образом, не создают отступов и читаются линейно.

Пример:

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;
}

По сравнению с:

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

Я хотел бы отметить, что это, кажется, хорошая идея, чтобы обобщить эти:

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