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

При раскрутке стека после panic! Rust последовательно уничтожает локальные значения, вышедшие из области видимости. Для типов, реализующих Drop, вызывается drop, поэтому ресурсы вроде файлов, блокировок и временных объектов освобождаются даже при аварийном завершении ветки.

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

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

В Rust управление временем жизни объектов основано на владении и детерминированном вызове деструкторов через Drop. Такой подход решает проблему освобождения ресурсов без сборщика мусора и сохраняет единое правило очистки как при обычном выходе из области видимости, так и при раскрутке стека.

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

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

Если при панике локальные значения не уничтожать, ресурсы могли бы оставаться занятыми: файл — открытым, mutex — захваченным, а память или временное состояние — недоступными для дальнейшей работы.

Однако Drop может содержать пользовательскую логику. Если она сама вызывает panic! во время уже идущей раскрутки, появляется вторая паника. Попытка продолжить такой процесс сделала бы результат очистки неоднозначным и могла бы привести к нарушению инвариантов.

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

При обычном выходе из области видимости Rust вызывает Drop для подходящих значений. При panic! в режиме раскрутки происходит то же освобождение локальных значений по мере разматывания каждого кадра стека; обычно локальные переменные уничтожаются в порядке, обратном их созданию в соответствующей области.

После завершения очистки паника передаётся дальше. Если она достигает catch_unwind, этот механизм получает Err, но уже выполненные деструкторы повторно не вызываются.

Режим компиляции с panic = "abort" отличается: процесс завершается немедленно, без раскрутки стека, поэтому локальные деструкторы при панике не гарантированно выполняются. Это уменьшает размер бинарного файла и упрощает поведение аварийного завершения, но исключает восстановление через catch_unwind.

Деструктор не должен паниковать. Особенно опасна паника в Drop, когда другая паника уже раскручивает стек: Rust немедленно прерывает процесс. Поэтому ошибки из операций очистки обычно нужно поглощать, регистрировать или хранить заранее, а не пытаться распространять через panic!.

use std::panic::catch_unwind;

struct Marker(&'static str);

impl Drop for Marker {
    fn drop(&mut self) {
        println!("drop {}", self.0);
    }
}

fn main() {
    let result = catch_unwind(|| {
        let _first = Marker("first");
        let _second = Marker("second");
        panic!("сбой");
    });

    assert!(result.is_err());
}

Перед возвратом из catch_unwind будут вызваны оба drop, причём локальные значения очищаются в обратном порядке объявления: сначала second, затем first. Сам факт перехвата паники не отменяет очистку.

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

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

Вариант с обычным режимом паники и корректным Drop сохраняет освобождение ресурса и позволяет изолировать панику на границе задачи. Вариант с panic = "abort" надёжно завершает процесс, но не даёт обработчику продолжить работу и не предоставляет гарантии выполнения Drop.

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

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

1. Вызывается ли Drop, если значение было частично перемещено?

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

2. Всегда ли catch_unwind гарантирует выполнение деструкторов?

Только при панике, распространяющейся через раскрутку стека. При режиме panic = "abort" процесс завершается сразу, поэтому деструкторы не являются гарантированным механизмом очистки. Кроме того, внешние факторы вроде принудительного завершения процесса также не обязаны запускать Drop.

3. Можно ли безопасно выполнять сложную логику в Drop во время паники?

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