Ответ на вопрос.
История вопроса
Обработка ошибок в C++ традиционно основывалась на исключениях или кодах ошибок. Исключения предоставляли чистый синтаксис, но несли накладные расходы во время выполнения и были трудными в использовании в детерминированных контекстах, таких как встроенные системы или системы реального времени. Коды ошибок были эффективными, но загрязняли сигнатуры функций и требовали ручной проверки распространения. C++23 представил std::expected, тип словаря, представляющий либо значение, либо ошибку, вдохновленный монадой функционального программирования, такой как Either в Haskell или Result в Rust.
Проблема
Хотя std::expected предоставляет монадные операции, такие как and_then, or_else и transform, эти операции требуют явного обращения с типом ошибки на каждом шаге цепочки композиции. В отличие от обработки на основе исключений, где ошибки автоматически поднимаются по стеку вызовов, пока не будут перехвачены, std::expected требует от программиста явно указывать, как ошибки преобразуются или передаются через каждую монадную привязку. Эта явность создает громоздкий код при объединении нескольких операций, которые могут завершиться неудачей, и требует тщательного рассмотрения преобразования типов ошибок, когда разные операции возвращают разные типы ошибок. Основная проблема заключается в том, что система типов C++ требует явного объединения типов ошибок в шаблонных инстанциациях, в отличие от динамической обработки исключений.
Решение
Монадный интерфейс std::expected в C++23 использует явную шаблонную механику для обеспечения безопасности типов и нулевых накладных расходов на абстракцию. Метод and_then требует, чтобы вызываемый возвращал другой std::expected с потенциально различными типами ошибок, а реализация использует SFINAE или концепции для проверки композиции. Для распространения типа ошибки разработчики должны явно обрабатывать преобразования типов, используя or_else или картировать типы ошибок с помощью transform_error. Этот явный подход обеспечивает видимость путей обработки ошибок в исходном коде и оптимизируемость компилятором, в отличие от скрытого управления потоком исключений. Решение принимает принципы функционального программирования, при этом уважая философию нулевых накладных расходов C++.
#include <expected> #include <string> #include <system_error> std::expected<int, std::error_code> parse_int(const std::string& s); std::expected<double, std::error_code> divide(int a, int b); // Явная обработка ошибок в композиции auto result = parse_int("42") .and_then([](int n) { return divide(100, n); }) .or_else([](std::error_code e) { return std::expected<double, std::error_code>(0.0); });
Ситуация из жизни
Команда разработчиков программного обеспечения для медицинских устройств нуждалась в реализации канала обработки данных, обрабатывающего показания датчиков с несколькими этапами валидации. Каждый этап мог завершиться неудачей с конкретными кодами ошибок (время ожидания оборудования, ошибка контрольной суммы, ошибка калибровки), которые нужно было передать в систему логирования с полной безопасностью типов.
Первый рассматриваемый подход заключался в использовании обработки ошибок на основе исключений с помощью иерархий std::runtime_error. Это позволяло автоматическое распространение вверх по стеку вызовов и чистое разделение обработки ошибок от бизнес-логики. Однако медицинские устройства требовали обеспечения детерминированной задержки, а исключения вводили непредсказуемые накладные расходы во время разворачивания стека. Этот подход также делал невозможным использование кода в ядрах GPU или встроенных контекстах, где исключения были отключены. Команде нужно было решение, которое работало бы в средах noexcept.
Второй рассматриваемый подход заключался в использовании традиционных кодов ошибок с помощью std::optional или std::variant с ручной проверкой ошибок после каждой операции. Это обеспечивало необходимую детерминированность и совместимость с noexcept. Однако код стал загроможденным повторяющимися проверками if (!result) после каждого этапа в канале. Распространение ошибок требовало ручной передачи кодов ошибок через стек вызовов, а объединение нескольких операций требовало вложенных условных операторов, что затрудняло логику потока данных. Типы ошибок также отсутствовали в безопасной обработке типов при смешивании различных категорий ошибок от различных датчиков.
Выбранным решением стал std::expected в C++23 с его монадным интерфейсом. Команда переписала канал так, чтобы использовать and_then для связывания этапов валидации и or_else для преобразования ошибок. Это сохранило линейный поток данных, обеспечивая при этом явные пути обработки ошибок. Решение предоставляло абстракцию с нулевыми накладными расходами, совместимую с ограничениями noexcept, и позволяло точно передавать типы ошибок в систему логирования. Переделка заняла три недели, после чего кодовая база поддерживала 15 различных типов датчиков с унифицированной обработкой ошибок.
Что часто упускают кандидаты
Как std::expected обрабатывает стирание типов при объединении операций, возвращающих разные типы ошибок?
Кандидаты часто упускают, что std::expected по умолчанию не выполняет стирание типов. При использовании and_then вызываемое должно вернуть std::expected с тем же типом ошибки, что и исходный, иначе программа не скомпилируется.
Чтобы обработать разные типы ошибок, разработчики должны явно преобразовывать ошибки с помощью transform_error или использовать std::expected с общим вариантом типа ошибки. В отличие от исключений, которые используют один статический тип для всех ошибок (обычно std::exception_ptr или базовые классы исключений), std::expected сохраняет строгую безопасность типов.
Этот дизайн предотвращает скрытые накладные расходы на стирание типов, но требует явного объединения типов ошибок на этапе компиляции. Понимание этого различия имеет решающее значение для композиции операций из разных библиотек с различными категориями ошибок.
Почему std::expected не предоставляет операцию монадной привязки, которая автоматически передает ошибки, как в случае обработки исключений?
Кандидаты часто путают std::expected с обработкой ошибок на основе исключений в отношении автоматического распространения. Они ожидают, что если операция в цепочке завершается неудачей, последующие операции будут автоматически пропущены без явной обработки.
Хотя and_then действительно пропускает вызываемую в случае ошибки, тип ошибки все равно должен быть явно обработан в конце цепочки или преобразован с помощью or_else. Основная причина заключается в том, что система типов C++ требует явной обработки всех возможных состояний ошибок для поддержания нулевых накладных расходов и детерминированного поведения.
Автоматическое распространение потребовало бы неявного управления потоком, аналогичного исключениям, что противоречит целям дизайна явных, оптимизируемых путей обработки ошибок. Std::expected придает приоритет производительности и безопасности типов выше синтаксического удобства.
Как спецификация noexcept операций монад std::expected влияет на гарантии безопасности исключений в цепочках композиции?
Кандидаты часто упускают, что монадные операции std::expected, такие как and_then и transform, условно являются noexcept в зависимости от вызываемых операций. Если вызываемый, переданный в and_then, является noexcept, вся цепочка остается noexcept.
Тем не менее, если вызываемый может выбросить исключение, операция может бросить std::bad_expected_access или распространить исключение в зависимости от конкретной реализации и стратегии обработки ошибок. Это условное всплытие noexcept позволяет разработчикам поддерживать сильные гарантии безопасности исключений на протяжении всей цепочки композиции.
Понимание этого имеет решающее значение для систем реального времени, где спецификации исключений влияют на генерацию кода и оптимизацию. Контракт noexcept распространяется по монадной цепочке, обеспечивая, чтобы обработка ошибок оставалась детерминированной и оптимизируемой компилятором.