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

Обработка прекращается на первом Err. collect возвращает именно эту ошибку, а ранее собранные успешные значения не становятся доступными в результате и фактически отбрасываются.

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

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

Такой подход решает типичную задачу: собрать все успешные элементы только тогда, когда ни один шаг не завершился ошибкой. Контроль потока остаётся явным, но шаблон раннего прекращения не приходится писать вручную.

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

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

При этом остановка не означает откат уже выполненной работы. Успешные элементы были обработаны, а внешние действия — например запись в журнал или сетевой запрос — не отменяются автоматически.

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

При вызове collect для итератора Result<T, E> Rust последовательно извлекает элементы. Каждый Ok(value) добавляется во временную коллекцию, а первый Err(error) немедленно становится итоговым значением Err(error).

fn main() {
    let mut attempts = 0;
    let result: Result<Vec<u32>, &str> = [Ok(1), Err("сбой"), Ok(3)]
        .into_iter()
        .map(|item: Result<u32, &str>| {
            attempts += 1;
            item
        })
        .collect();

    println!("{result:?}; попыток: {attempts}");
}

Результат содержит ошибку сбой, а число попыток равно двум: элемент после ошибки не извлекается и не обрабатывается. Тип результата нужен явно или должен быть однозначно выведен из контекста, поскольку collect может собирать разные виды коллекций.

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

Если источник данных имеет побочные эффекты, остановка итерации может оставить внешнюю систему в частично обработанном состоянии. В таком случае следует заранее выбрать между fail-fast-поведением, накоплением ошибок или отдельным транзакционным механизмом.

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

Сервис читает строки конфигурации и преобразует каждую в числовой идентификатор. Вариант с collect::<Result<Vec<_>, _>>() быстро прекращает загрузку при первой некорректной строке. Его плюс — простой контракт: вызывающий код получает либо полностью собранные данные, либо одну ошибку; минус — пользователь не видит остальные ошибки.

Другой вариант — обработать все строки вручную и накопить ошибки в отдельный список. Он лучше для пакетной валидации, но требует определить правила для частично корректных данных и усложняет код.

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

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

Вопрос: Прекращает ли collect выполнение итератора после первой ошибки?

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

Стандартный результат collect для Result имеет форму Result<Коллекция<T>, E>, поэтому при ошибке он возвращает только Err(E). Если частичная коллекция нужна, это следует выразить отдельным типом результата или написать собственную логику накопления; стандартный collect её наружу не выдаёт.
Вопрос: Когда collect с Result нужно заменить накоплением всех ошибок?

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