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

Сначала будет напечатано освобождён ресурс, затем Err("сбой"). Оператор ? инициирует ранний возврат из функции, а перед возвратом Rust автоматически вызывает Drop для всех уже созданных локальных значений, включая _guard.

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

В Rust обработка ошибок строится вокруг явных типов Result и Option, а не вокруг обязательных исключений. Поэтому функция может завершиться раньше обычного пути через return Err(...), но при этом ресурсы должны освобождаться предсказуемо.

Механизм владения и трейта Drop решает эту задачу по принципу очистки при выходе значения из области видимости. Это позволяет безопасно закрывать файлы, освобождать блокировки и откатывать транзакции даже при распространении ошибки через ?.

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

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

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

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

Оператор ? для Result концептуально преобразуется в сопоставление: при Ok(value) выполнение продолжается, а при Err(error) функция немедленно возвращает эту ошибку. Перед фактическим выходом из функции Rust уничтожает локальные значения, чьи области видимости завершаются.

В примере _guard был создан до выражения с ?, поэтому при возврате Err вызывается его метод drop. После этого main получает результат Err("сбой") и печатает его через Debug.

struct Guard(&'static str);

impl Drop for Guard {
    fn drop(&mut self) {
        println!("освобождён {}", self.0);
    }
}

fn operation() -> Result<(), &'static str> {
    let _guard = Guard("ресурс");
    Err("сбой")?;
    Ok(())
}

fn main() {
    println!("{:?}", operation());
}

Вывод будет таким:

освобождён ресурс
Err("сбой")

Drop вызывается не самим оператором ?, а процедурой выхода из области видимости. Значения уничтожаются в соответствии с их временем жизни; локальные переменные, созданные в одной области, обычно уничтожаются в обратном порядке объявления.

Есть важные ограничения. Метод Drop::drop не может вернуть Result, поэтому ошибку очистки нельзя напрямую передать через ?. Кроме того, значение, перемещённое из текущей переменной, больше не будет уничтожено через старое имя, а значения, которые не успели создаться, очищать не нужно.

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

Допустим, функция изменяет данные в транзакции. Вариант с ручным откатом вызывает rollback() перед каждым return Err(...), но при добавлении нового пути ошибки разработчик может забыть этот вызов. Такой подход даёт возможность обработать ошибку отката, но плохо масштабируется и подвержен пропускам.

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

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

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

Вызывается ли Drop у переменной, объявленной после места с ??

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

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

Нет. Возвращаемое значение уже сформировано, а локальные значения уничтожаются в процессе выхода из функции. Drop может изменить внешнее состояние или вызвать panic!, но не заменить исходный Ok или Err обычным возвращаемым значением. Паника из Drop особенно опасна во время уже идущей раскрутки стека: повторная паника обычно приводит к аварийному завершению процесса.