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

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

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

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

в boost::optional<T> тоже зашит эксепшн? ну тогда он мне тоже не нравится мне нравится сама идея — возможность самому расширять любой тип значением undefined, чтобы замкнуть хотя бы какие-то операции


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

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

а я думал, это что-то из разряда хаскелловской монады Maybe

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

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

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

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

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

ну как же не замусоренную, если вам придется продумывать "а что будет, если вот именно в этом месте поток исполнения прервется и пойдет по совсем другому пути" и вставлять предусматривающий такой ход код?
кроме того, одна и та же нештатная ситуация может быть критической в одном случае и некритической в другом. и если она может возникнуть, например, в функции f() которую вы используете в нескольких местах, то вам придется во всех местах использования ставить трай-кэтчи, замусоривая код, тогда как в случае с аналогом NaN такой необходимости не будет.

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