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

Программа напечатает "" — пустую строку. Метод Result::unwrap_or_default извлекает успешное значение, а при Err возвращает Default::default() для типа успеха String; исходная ошибка полностью теряется.

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

Result<T, E> предназначен для явного представления успешного результата или причины сбоя. При этом Rust предоставляет удобные методы для случаев, когда приложение сознательно выбирает безопасное или нейтральное значение вместо обработки ошибки.

unwrap_or_default относится именно к такому сценарию: он сокращает код, когда тип T имеет реализацию Default, а отсутствие результата допустимо. Это не механизм логирования, восстановления причины ошибки или её передачи выше.

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

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

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

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

Для Result<String, E> вызов unwrap_or_default() работает концептуально так:

let config = match load_config() {
    Ok(value) => value,
    Err(_) => String::default(),
};

String::default() создаёт пустую строку. Ошибка не преобразуется, не сохраняется и не возвращается; значение Err отбрасывается.

Метод не вызывает panic, в отличие от unwrap. Поэтому он подходит, когда fallback действительно является частью контракта функции. Если ошибка должна быть видна пользователю, записана в журнал или передана вызывающему коду, следует использовать match, map_err, ? либо явный метод обработки ошибки.

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

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

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

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

Практичное решение — разделить данные по обязательности: для необязательного кэша применить fallback и отдельно записать ошибку в журнал, а для обязательных параметров вернуть ошибку через ?. Так сохраняется управляемость отказа без ненужного падения из-за второстепенных данных.

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

Чем unwrap_or_default отличается от unwrap_or?

unwrap_or принимает конкретное значение-запасной вариант, а unwrap_or_default получает его через Default::default() для типа T. Например, для String это пустая строка, для Vec<T> — пустой вектор, для числового типа — ноль.

В обоих случаях ошибка отбрасывается. Разница в том, задаётся ли fallback явно или выбирается соглашением типа Default.
Вычисляется ли запасное значение лениво в unwrap_or_default?

Да, отдельное дорогое выражение для fallback не передаётся: метод просто вызывает Default::default() только в ветке Err. Если нужен собственный потенциально затратный fallback, следует рассмотреть unwrap_or_else, поскольку его замыкание также выполняется только при ошибке.

Однако это не означает, что unwrap_or_default сохраняет ошибку. Ленивая генерация значения и диагностика ошибки — независимые вопросы.
Как сохранить диагностику, если сервис всё же должен продолжить работу?

Ошибку нужно обработать до выбора fallback, например через inspect_err, если достаточно побочного эффекта, или через явный match, если требуется сложная логика:
```
let config = load_config()
    .inspect_err(|error| eprintln!("ошибка конфигурации: {error}"))
    .unwrap_or_default();
```
В этом варианте успешное значение и ошибка не преобразуются методом inspect_err, но при Err записывается диагностика, после чего применяется пустая строка. Такой подход всё равно осознанно скрывает ошибку от вызывающего кода, поэтому для обязательных данных лучше вернуть Result, а не использовать fallback.