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

Точка входа Rust обрабатывает возвращаемое из main значение через трейт Termination. Для Result<T, E> успешный вариант передаёт управление как успешное завершение, а Err форматируется для диагностики и преобразуется в неуспешный код завершения.

Оператор ? только досрочно возвращает Err из main; само завершение процесса выполняет инфраструктура запуска программы после вызова main.

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

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

Подход с Termination позволяет использовать обычную модель Result вместо ручной проверки каждой ошибки в main. Это уменьшает шаблонный код и сохраняет ошибки частью статической сигнатуры функции.

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

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

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

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

Возвращаемый тип main должен реализовывать Termination. Для Result<T, E> стандартная реализация требует, чтобы успешный тип T поддерживал Termination, а тип ошибки E поддерживал Debug.

При Ok вызывается отчёт успешного значения. В типичном случае Result<(), E> это означает успешное завершение. При Err(error) стандартная реализация выводит ошибку с использованием Debug и возвращает код, обозначающий неуспешное завершение.

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

use std::fs;

fn main() -> Result<(), std::io::Error> {
    let text = fs::read_to_string("config.toml")?;
    println!("{}", text.len());
    Ok(())
}

Если файл не прочитан, ? возвращает Err из main. Затем механизм запуска применяет Termination к этому Result: ошибка диагностируется, а процесс завершается с неуспешным статусом. Если чтение успешно, выполняется Ok(()), и программа завершается успешно.

Это отличается от panic: Err является штатным результатом функции и проходит через контракт Result, тогда как panic! запускает механизм аварийного завершения или раскрутки стека. Возврат ошибки из main сам по себе не раскручивает стек.

Стандартный вывод ошибки использует Debug, поэтому для пользовательского CLI он может быть слишком техническим. Если нужен единообразный формат сообщений, можно обработать ошибку вручную перед выходом либо создать собственный тип-обёртку с реализацией Termination. Для библиотечного кода завершать процесс обычно не следует: библиотека должна возвращать Result, оставляя решение о выводе и завершении приложению.

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

Командная утилита читает конфигурацию, проверяет её и запускает сервер. Возможны такие варианты:

Вызывать unwrap или expect на каждом шаге. Это коротко, но превращает ожидаемые ошибки ввода, прав доступа или формата в panic и ухудшает поведение утилиты.
Вручную сопоставлять каждый Result, печатать сообщение и вызывать process::exit. Это даёт полный контроль, но создаёт повторяющийся код и усложняет единообразное добавление контекста.
Возвращать из main единый тип ошибки через Result и использовать ?. Это сохраняет ранний выход, статическую проверку ошибок и корректный неуспешный статус.

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

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

Вопрос: Может ли main возвращать Result с любым типом успешного значения?

Ответ: Нет. Успешный тип должен реализовывать Termination. Поэтому распространённая форма — Result<(), E>: тип () поддерживает нужный контракт. Произвольная структура или строка не становятся допустимым результатом main автоматически только потому, что находятся внутри Result.
Вопрос: Достаточно ли для ошибки в Result реализовать std::error::Error?

Ответ: Для стандартной обработки Result из main ключевым требованием является Debug, а не обязательная реализация std::error::Error. Трейт Error полезен для построения цепочки причин и совместимости с экосистемой ошибок, но сам по себе не является условием механизма Termination для Result.
Вопрос: Можно ли изменить текст и код завершения, реализовав Termination непосредственно для стандартного Result?

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