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

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

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

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

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

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

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

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

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

Обратная ошибка тоже существенна: panic из-за неправильного пользовательского ввода завершает поток или процесс вместо контролируемого отказа. Кроме того, паника усложняет интеграцию библиотек: вызывающий код не видит её в типе API и не может обычным способом сопоставить её с доменной ошибкой.

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

Граница обычно определяется вопросом: «Может ли корректный вызывающий код столкнуться с этим условием при нормальной эксплуатации?» Если да, условие следует представить через Result. Если условие свидетельствует о нарушении инварианта, который должен обеспечиваться самой программой, допустим panic.

use std::num::ParseIntError;

fn parse_limit(text: &str) -> Result<u32, ParseIntError> {
    text.parse()
}

fn require_nonempty(text: &str) -> &str {
    assert!(!text.is_empty(), "нарушен внутренний инвариант");
    text
}

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

Паника не всегда немедленно завершает весь процесс: стандартная стратегия может раскручивать стек, а конфигурация panic = "abort" может завершать процесс сразу. Однако полагаться на перехват паники как на обычную обработку ошибок не следует; catch_unwind предназначен для специальных границ изоляции, а не для повседневного управления потоком.

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

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

Сервис принимает от клиента максимальный размер загружаемого файла. Неверное число, отрицательное значение после разбора или превышение разрешённого лимита — нормальные варианты пользовательского ввода. Команда рассмотрела два решения: вызывать panic при любом несоответствии, что упрощало код, но позволяло клиенту ронять обработчик; либо возвращать Result с доменной ошибкой, что требовало дополнительной обработки, зато позволяло ответить клиенту кодом валидации.

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

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

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

1. Может ли библиотека использовать panic для неправильных аргументов публичной функции?

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

2. Чем нарушение инварианта отличается от ошибки бизнес-правила?

Бизнес-правило является частью нормальной предметной области: например, операция запрещена при недостаточном балансе. Это не дефект программы, поэтому его следует вернуть как доменную ошибку через Result. Инвариант — условие, которое реализация обязалась поддерживать всегда; его нарушение указывает на ошибку в коде или повреждение состояния и может оправдать panic.

3. Почему нельзя автоматически преобразовывать любую панику в Result на границе приложения?

Такое преобразование может скрыть дефекты и создать видимость, что сбой был штатно обработан. Кроме того, не всякое состояние безопасно продолжать после паники, а при стратегии abort перехват невозможен. Изоляция через catch_unwind уместна в специальных границах, например при защите хоста от непредсказуемого кода, но для обычных ошибок нужно проектировать явные варианты Result.