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

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

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

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

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

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

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

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

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

Рассмотрим минимальный пример:

#include <iostream>

struct Trace {
    int id;
    ~Trace() { std::cout << id << ' '; }
};

void run() {
    Trace first{1};
    Trace second{2};
}

int main() { run(); }

При выходе из run будет напечатано 2 1: сначала уничтожается second, затем first. Для локальных объектов важен порядок, в котором завершилось их конструирование, а не только порядок записанных объявлений.

Если конструктор second выбросит исключение, деструктор second не вызывается, потому что его объект не был полностью создан. Деструктор first будет вызван во время раскрутки стека.

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

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

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

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

Можно было бы освобождать ресурсы вручную перед каждым return и в каждом обработчике исключений. Такой вариант даёт явный контроль, но дублирует логику и легко оставляет ресурс неосвобождённым на новом пути выхода.

Предпочтительное решение — обернуть каждый ресурс в объект с корректным деструктором и объявлять объекты в порядке, обратном зависимости их очистки. Тогда обычный выход, ранний return и исключение используют один и тот же надёжный механизм; цена решения — необходимость правильно спроектировать владельцев ресурсов.

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

Вызывается ли деструктор объекта, если его конструктор выбросил исключение?

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

Что произойдёт с локальными объектами при return из функции?

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

Можно ли изменить порядок разрушения локальных объектов списком инициализации?

Нет. Для локальных объектов порядок определяется последовательностью их создания в потоке выполнения. Для членов класса порядок задаётся объявлениями членов и базовых подобъектов, поэтому перестановка элементов списка инициализации конструктора не меняет порядок разрушения.