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

JoinHandle::join оборачивает результат потока во внешний Result. Если поток штатно завершился, join возвращает Ok(значение_потока), даже если самим значением является Err; если поток завершился паникой, join возвращает внешний Err с payload паники.

Для потока, возвращающего Result<T, E>, итоговый тип фактически имеет форму Result<Result<T, E>, Box<dyn Any + Send + 'static>>.

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

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

Поэтому join не смешивает ошибку бизнес-операции с аварийным завершением потока: они находятся на разных уровнях результата.

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

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

Смешивание этих случаев приводит к неверной реакции. Например, обработка паники как обычной ошибки может скрыть нарушение инварианта, а трактовка обычного Err как аварии — привести к ненужному завершению сервиса.

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

Сначала анализируется внешний результат join. Внешний Ok означает, что поток завершился без паники; его содержимое затем проверяется как обычный Result. Внешний Err содержит payload, переданный в panic!, но этот payload не обязан реализовывать std::error::Error.

use std::thread;

fn main() {
    let handle = thread::spawn(|| -> Result<(), &'static str> {
        Err("ошибка операции")
    });

    match handle.join() {
        Ok(Ok(())) => println!("успех"),
        Ok(Err(error)) => println!("ошибка операции: {error}"),
        Err(payload) => println!("поток запаниковал: {}", payload.is::<&str>()),
    }
}

Здесь Ok(Err(error)) означает штатное завершение потока с ошибкой операции. Вариант Err(payload) означает, что замыкание не вернуло значение из-за паники. Для извлечения текста payload обычно проверяют его тип через downcast_ref::<String>() или downcast_ref::<&'static str>(); рассчитывать только на строковое представление нельзя.

После возврата Err из join поток уже завершён, поэтому повторно присоединить его нельзя: join потребляет JoinHandle. При режиме panic = abort раскрутки стека нет, и паника завершает весь процесс, поэтому получить такой Err через join не удаётся.

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

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

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

Лучше сначала обработать внешний результат join, зарегистрировать панику как аварийное завершение, а затем отдельно обработать внутренний Result. Такой дизайн сохраняет семантическое различие и позволяет решить, нужно ли перезапускать поток, останавливать сервис или продолжать работу.

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

Является ли Err из join обычным типом ошибки приложения?

Нет. Его тип — Box<dyn Any + Send + 'static>, потому что payload паники может иметь произвольный тип, удовлетворяющий этим ограничениям. Он не обязан реализовывать std::error::Error, поэтому для включения паники в единый тип ошибок нужна явная адаптация, например извлечение строки или создание собственного варианта ошибки.
Что произойдёт с другими потоками после паники рабочего потока?

Сам по себе join не завершает другие потоки и не превращает панику в глобальное исключение. Панический поток прекращает работу, а остальные могут продолжить выполнение; решение о завершении процесса принимает код, обрабатывающий результат join.
Можно ли считать Ok(Err(e)) и Err(payload) взаимозаменяемыми?

Нет. Ok(Err(e)) означает, что поток корректно вернул предусмотренную ошибку, поэтому его код завершения и очистка прошли штатно. Err(payload) означает досрочное завершение из-за паники; это обычно сигнал дефекта, нарушенного инварианта или другой непредусмотренной ситуации.