Гепардово гнездо

Про throwing values

Расскажу коротко про throwing values (они же иногда называются herbceptions, потому что предложил их Herb Sutter). Полностью прочитать можно здесь, а я лишь отмечу основные моменты:
* функции, которые кидают исключение, помечены как throws, при этом по сути они возвращают исключение просто как значение, в регистрах (почти как Result<T, E> в Rust и std::expected<>)
* такие «исключения» пробрасываются автоматически и синтаксически ловятся try/catch как обычные, хотя на самом деле в этом случае раскрутка стека не используется. Конечно, можно их так не реализовывать, а сделать почти как в Rust и требовать подобие оператора ?, чтобы явно пробрасывать ошибку
* все исключения лежат в типе std::error размером с два указателя (чем-то похоже на гошный тип error и существующий в C++ std::error_code). Первая половина — это категория ошибки, а вторая — ее содержание (просто код ошибки для простых случаев, указатель на подробное описание для сложных, в зависимости от категории). В статье приводится также мотивация в пользу единого типа ошибок std::error вместо кучи разных типов как в текущей реализации исключений

Также в proposal'е предлагается добавить _Either(T, E) в Си для поддержания совместимости, а еще оптимизации вида «юзать регистр флагов, чтобы понять, вернулась ошибка или значение».

На картинке выше (которую я честно украл из статьи) показывается сравнение синтаксиса throwing values и std::expected<>, где видно, что код со throwing values выглядит гораздо проще.

Наверное, можно было бы еще поговорить на эту тему, но я вас уже и так закидал кучей разного текста на сегодня, поэтому остановимся здесь :)

www.group-telegram.com/jp/gepardchan.com/139

1.6K viewsedited  Jun 24 at 13:42

Про throwing values

Расскажу коротко про throwing values (они же иногда называются herbceptions, потому что предложил их Herb Sutter). Полностью прочитать можно здесь, а я лишь отмечу основные моменты:
* функции, которые кидают исключение, помечены как throws, при этом по сути они возвращают исключение просто как значение, в регистрах (почти как Result<T, E> в Rust и std::expected<>)
* такие «исключения» пробрасываются автоматически и синтаксически ловятся try/catch как обычные, хотя на самом деле в этом случае раскрутка стека не используется. Конечно, можно их так не реализовывать, а сделать почти как в Rust и требовать подобие оператора ?, чтобы явно пробрасывать ошибку
* все исключения лежат в типе std::error размером с два указателя (чем-то похоже на гошный тип error и существующий в C++ std::error_code). Первая половина — это категория ошибки, а вторая — ее содержание (просто код ошибки для простых случаев, указатель на подробное описание для сложных, в зависимости от категории). В статье приводится также мотивация в пользу единого типа ошибок std::error вместо кучи разных типов как в текущей реализации исключений

Также в proposal'е предлагается добавить _Either(T, E) в Си для поддержания совместимости, а еще оптимизации вида «юзать регистр флагов, чтобы понять, вернулась ошибка или значение».

На картинке выше (которую я честно украл из статьи) показывается сравнение синтаксиса throwing values и std::expected<>, где видно, что код со throwing values выглядит гораздо проще.

Наверное, можно было бы еще поговорить на эту тему, но я вас уже и так закидал кучей разного текста на сегодня, поэтому остановимся здесь :)

BY Гепардово гнездо