Краткий ответ

При распространении исключения C++ уничтожает все уже созданные автоматические объекты, находящиеся в покидаемых областях видимости. Поэтому RAII-объект освобождает принадлежащий ему ресурс в деструкторе независимо от того, произошёл обычный выход из функции или аварийный выход через исключение.

Исторический контекст

RAII сформировался как способ связать управление ресурсом с временем жизни объекта. Исходная проблема состояла в том, что ручное освобождение памяти, файлов, блокировок и других ресурсов легко пропустить на одном из многочисленных путей выхода из функции.

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

Постановка проблемы

Функция может завершиться несколькими способами: вернуть результат, выбросить исключение или вызвать другую функцию, которая выбросит исключение. Если освобождение ресурса записано только в конце функции, при исключении этот код не будет выполнен.

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

Подробное решение

При входе в область видимости локальный RAII-объект конструируется и принимает ресурс. Когда выполнение покидает область видимости из-за исключения, сначала выполняется раскрутка стека: уничтожаются уже созданные локальные объекты в обратном порядке их конструирования, после чего исключение передаётся выше.

Деструктор RAII-объекта должен корректно освобождать ресурс и обычно не должен выбрасывать исключения. Если деструктор выбросит исключение во время уже идущей раскрутки стека, программа может завершиться через std::terminate.

RAII гарантирует очистку только для объектов, которые уже успешно сконструированы. Если конструктор объекта завершился исключением, его деструктор для этого объекта не вызывается, но уже полностью сконструированные подобъекты и базовые классы уничтожаются.

Для памяти обычно применяют std::unique_ptr, для блокировок — std::lock_guard или std::unique_lock, для файлов — объект-обёртку с закрытием в деструкторе. Сырые указатели сами по себе не выражают владение и не обеспечивают автоматическое освобождение.

Минимальный пример:

#include <memory>
#include <stdexcept>

void process() {
    auto resource = std::make_unique<int>(42);
    throw std::runtime_error("failure");
}

Перед распространением исключения уничтожается resource, а его деструктор освобождает память. Явный вызов delete в конце функции здесь не нужен и был бы недостижим при исключении.

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

Ситуация из практики

Сервис загружает временный буфер для обработки сообщения. В середине обработки может возникнуть исключение из-за некорректного формата входных данных. Варианты — освобождать буфер вручную перед каждым return и каждым throw, использовать общий блок очистки или передать владение std::unique_ptr.

Ручная очистка проста для одного пути, но легко ломается при добавлении нового выхода. Общий блок очистки уменьшает дублирование, однако требует аккуратно поддерживать переходы управления и не решает проблему владения так явно, как тип.

Выбран std::unique_ptr: он автоматически освобождает буфер при обычном выходе и при исключении, а единственность владения предотвращает двойное освобождение. В результате добавление новых проверок не создаёт новых мест, где нужно вручную освобождать память.

Что кандидаты часто упускают

Что произойдёт с локальным RAII-объектом при исключении, если исключение будет перехвачено выше?

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

Гарантирует ли RAII откат изменений, сделанных во внешней системе?

Нет. RAII автоматически вызывает деструктор и может освободить локальный ресурс, но не знает, как отменять уже отправленный сетевой запрос, запись в базе данных или изменение файла. Для таких операций нужен отдельный объект транзакции с явным commit, а в деструкторе — безопасный откат, если он действительно возможен.

Почему порядок уничтожения RAII-объектов важен?

Локальные объекты уничтожаются в порядке, обратном порядку их успешного создания. Это позволяет сначала уничтожить объект, зависящий от другого ресурса, а затем его зависимость. Если зависимости объявлены в неверном порядке, деструктор может обратиться к уже освобождённому ресурсу, что приводит к неопределённому поведению или ошибке протокола освобождения.