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

Если файл отсутствует, read_to_string вернёт Err, оператор ? немедленно завершит main с этой ошибкой. Среда выполнения вызовет реализацию Termination для Result, выведет описание ошибки в стандартный поток ошибок и завершит процесс с неуспешным кодом.

Это не panic: раскрутки стека не происходит, а локальные значения уничтожаются как при обычном возврате из функции.

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

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

Возврат Result из main разделяет две ответственности: функция описывает ошибку типом Result, а механизм Termination преобразует итог работы программы в вывод и код завершения процесса.

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

Вызов read_to_string может завершиться ошибкой ввода-вывода: файл может отсутствовать, быть недоступен для чтения или содержать проблемы, связанные с файловой системой. Если использовать unwrap, такая ситуация превратится в panic, хотя она является ожидаемой операционной ошибкой.

Если функция main возвращает Result<(), std::io::Error>, оператор ? может передать ошибку напрямую вызывающему коду — в данном случае среде выполнения программы. Нельзя ожидать, что программа продолжит выполнение после строки с ? при результате Err.

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

Тип Result<(), std::io::Error> означает: успешное завершение обозначается Ok(()), а ошибка — Err(std::io::Error). Метод read_to_string возвращает Result<String, std::io::Error>, поэтому тип ошибки совпадает с типом ошибки main, и дополнительное преобразование не требуется.

Оператор ? извлекает строку из Ok. При Err он выполняет ранний возврат из main с этой ошибкой. Поэтому println! и Ok(()) в таком сценарии не выполняются.

Для Result, возвращаемого из main, Rust использует механизм Termination. При Ok(()) процесс завершается успешно. При Err(error) ошибка форматируется для диагностики, обычно выводится через стандартный поток ошибок, а процесс получает код неуспешного завершения. Точное текстовое представление std::io::Error зависит от операционной системы и конкретной причины сбоя.

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

use std::fs;

fn main() -> Result<(), std::io::Error> {
    match fs::read_to_string("config.toml") {
        Ok(text) => println!("{}", text.len()),
        Err(error) => eprintln!("конфигурация недоступна: {error}"),
    }
    Ok(())
}

В этом варианте ошибка не передаётся механизму Termination: программа сама выводит сообщение и затем возвращает Ok(()). Следовательно, процесс завершится успешно, что может быть неверно для обязательной конфигурации.

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

Сервису требуется обязательный файл конфигурации. Вариант с unwrap прост, но приводит к panic, загрязняет диагностику трассировкой стека и смешивает ошибку окружения с программной ошибкой. Вариант с большим match позволяет дать собственное сообщение, но при неаккуратной реализации может вернуть успешный код после критического сбоя.

Выбранный вариант — main -> Result<(), std::io::Error> с ?, если стандартного описания ошибки достаточно. Он сохраняет типизированную ошибку, прекращает запуск до инициализации сервиса и возвращает неуспешный код для оболочки, менеджера процессов или контейнерного оркестратора.

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

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

Обязательно ли main возвращать именно Result<(), E>?

Нет, поддерживается Result<T, E>, если успешный тип T и ошибка E удовлетворяют требованиям механизма Termination. Для распространённого случая Result<(), E> ошибка должна поддерживать Debug, поэтому std::io::Error подходит. Само наличие Result не означает, что любая произвольная структура ошибки автоматически может быть возвращена из main.

Продолжится ли выполнение после ?, если ошибка возникла внутри main?

Нет. ? выполняет ранний возврат из текущей функции. Код после выражения с ? не запускается, а локальные переменные, уже созданные в main, корректно освобождаются при выходе из области видимости. Продолжение возможно только если ошибка была перехвачена и обработана явно, например через match или unwrap_or_else.

Сохраняется ли исходная ошибка как числовой код завершения процесса?

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