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

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

При panic=unwind Rust раскручивает стек, вызывает Drop для уже созданных локальных значений и может передать панику в catch_unwind. Это удобнее для изоляции паники, но обычно требует дополнительного кода и ресурсов.

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

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

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

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

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

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

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

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

При unwind паника распространяется вверх по стеку. На каждом разматываемом кадре Rust уничтожает уже инициализированные локальные значения в соответствии с правилами владения, поэтому их реализации Drop выполняются. Если паника достигает catch_unwind, она превращается в Result, и внешний код может продолжить работу.

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

Минимальная иллюстрация различия:

use std::panic::catch_unwind;

struct Guard;
impl Drop for Guard {
    fn drop(&mut self) { println!("Drop выполнен"); }
}

fn main() {
    let result = catch_unwind(|| {
        let _guard = Guard;
        panic!("сбой");
    });
    println!("перехвачено: {}", result.is_err());
}

При panic=unwind перед выводом о перехвате будет вызван Drop, а result.is_err() даст true. При panic=abort процесс завершится на panic!, поэтому код после неё, включая вывод и перехват, не выполнится.

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

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

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

В сервисе обработки изображений сторонний плагин запускается внутри catch_unwind. Один вариант — собрать приложение с panic=abort: это делает поведение простым, но одна ошибка плагина завершает весь сервис, а перезапуск переносится на внешний менеджер процессов.

Второй вариант — оставить panic=unwind и перехватывать панику на границе плагина. Плюс — падение одного плагина не обязательно останавливает сервис; минус — нужно доказать, что после паники общие данные и инварианты остаются корректными. Сам catch_unwind не заменяет изоляцию памяти или процесса.

Для сервиса, где важна доступность и плагин не разделяет изменяемое состояние без строгой защиты, выбирают unwind на границе плагина, регистрируют факт паники и переводят конкретную задачу в состояние ошибки. Если же плагин потенциально повреждает общий процессный state, безопаснее использовать отдельный процесс; смена panic=unwind сама по себе такую изоляцию не обеспечивает.

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

Можно ли гарантировать выполнение Drop при любой панике?

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

Достаточно ли изменить стратегию паники, чтобы безопасно продолжить работу после catch_unwind?

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

Что произойдёт с паникой в потоке при разных стратегиях?

При unwind паника сначала распространяется внутри потока; если её не перехватить в самом потоке, присоединяющий поток может получить информацию о панике через результат join. При abort раскрутки нет, и паника завершает весь процесс, поэтому граница потока не становится средством изоляции. Для настоящей защиты процесса от падения компонента нужна отдельная процессная граница, а не только новый поток.