Здравствуйте, _hum_, Вы писали:

EP>>Есть некий симбиоз возвращаемых значений и исключений — expected<T>
__>выглядит страшнова-то.. а вот указанный boost::optional<T> уже "ближе", но все равно еще не то...

От Optional отличие только в том, что внутри могут хранится разные исключения, а не только bad_optional_access.

__>>>Или каких-нибудь замыканий (монад?), наподобие добавления к множеству возможных числовых результатов операций значения NaN, которое выводит деление на нуль из области исключительных ситуаций, и тем самым позволяет избавиться от уймы проверок на промежуточных этапах?
EP>>Исключения это и есть монада, которая позволяет "избавиться от уймы проверок на промежуточных этапах"
__>мм... может, я неправильно выразился. я имел ввиду подход, когда вместо того, чтобы считать a/0 неопределенностью, просто расширяют тип вещественных чисел за счет введения значения NaN, для которого полагается
__> a @ NaN -> NaN
__> NaN @ NaN -> NaN
__>(здесь @ — любая операция)

Это аппликативный функтор, а не монада.

__>в этом случае даже если у вас произойдет деление на нуль, поток управления все равно продолжит течь, как ни в чем не бывало, предоставляя вам свободу выбора, где делать проверку на валидность соответствующего значения.

Монада в этом контексте как раз и отличается от аппликативного функтора тем что может прервать поток управления, так как весь этот поток управления протекает через неё.

__>в случае же с эксепшенами обычный поток управления с необходимостью будет прерываться. а значит, программисту придется "всовывать" в обычную логику еще и логику перехватов и обработок исключений.

Вообще-то наоборот — с исключениями мы имеем обычную логику не замусоренную проверками и обработками. Обработка же обычно происходит где-то наверху стэка.