Re[2]: А идет ли развитие в области альтернатив исключениям?
От: _hum_ Беларусь  
Дата: 26.03.16 12:02
Оценка:
Здравствуйте, LaptevVV, Вы писали:

__>>В с++ в направлении усовершенствования исключений идет заметное движение. А как вообще в мире и в с++ в частности обстоит дело с развитием альтернатив исключениям (теми же кодами возвратов ошибок)?

LVV>Да дело не в инструменте как таковом.
LVV>Если ты для каждого состояния системы рассмотришь не только рабочие состояния, но и аварийные...
LVV>Если ты рассклассифицируешь эти аварийные состояния по степени тяжести...
LVV>Если ты спроектируешь реакцию системы в каждом классе аварийных состояний...
LVV>Если ты напишешь все сообщения для аварийных состояний...
LVV>Тогда можно посмотреть в сторону инструмента — как это все реализовать.
LVV>ИМХО в этом случае аппарата исключений вполне достаточно.
LVV>А в системах реального времени — коды возврата (если средство разработки для этого подходящее)

нет, дело именно в инструментарии, потому как иногда из-за его отсутствия приходится пересматривать понятие "аварийность" (когда обрабатывать некритические ошибки становится настолько громозко, что проще сделать их критическими с вызовом abort()")
Re[3]: А идет ли развитие в области альтернатив исключениям?
От: LaptevVV Россия  
Дата: 26.03.16 12:29
Оценка:
LVV>>Тогда можно посмотреть в сторону инструмента — как это все реализовать.
LVV>>ИМХО в этом случае аппарата исключений вполне достаточно.
LVV>>А в системах реального времени — коды возврата (если средство разработки для этого подходящее)
__>нет, дело именно в инструментарии, потому как иногда из-за его отсутствия приходится пересматривать понятие "аварийность" (когда обрабатывать некритические ошибки становится настолько громозко, что проще сделать их критическими с вызовом abort()")
А разве в С++ инструмент отсутствует?
Мне, например, исключений хватает за глаза.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: А идет ли развитие в области альтернатив исключениям?
От: Evgeny.Panasyuk Россия  
Дата: 26.03.16 13:01
Оценка: +2
Здравствуйте, _hum_, Вы писали:

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

__>в boost::optional<T> тоже зашит эксепшн?

Если он пустой, и безусловно доставать из него значение — да, будет исключение.

__>мне нравится сама идея — возможность самому расширять любой тип значением undefined, чтобы замкнуть хотя бы какие-то операции


Мне не нравится инфицирование всех выражений undefined'ом.

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

__>>> a @ NaN -> NaN
__>>> NaN @ NaN -> NaN
__>>>(здесь @ — любая операция)
EP>>Это аппликативный функтор, а не монада.
__>а я думал, это что-то из разряда хаскелловской монады Maybe

Каждая монада это аппликативный функтор, но не наоборот. Если использовать именно монадические свойства Maybe, например через Haskell'евский do-синтаксис, то на первом Nothing'е весь поток управления остановится, собственно для этого и происходит заворачивание в do-синтаксис, чтобы был контроль над потоком управления (что особенно видно если вручную расписать замыкания и bind'ы).

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

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

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

Их изначально именно и протаскивали ради императивных вещей, в частности таких как ввод-вывод.
Собственно исключения в Haskell именно как монада и реализованы.

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


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


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


Если речь идёт про Exception safety, то на C++ обычно всё что требуется для basic guarantee было бы и без исключений. Если же речь про strong guarantee, которую часто ассоциируют с транзакционностью — то её придётся "продумывать" в любом языке

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


Почему же во всех местах использования? Только в тех, где это критично.

__>тогда как в случае с аналогом NaN такой необходимости не будет.


Если в каком-то месте критично чтобы вызов f() прошёл нормально, вернув нормальный результат, то и в случае с NaN'ами придётся городить проверки

__>другими словами, ексепшены принуждают программиста под угрозой повалить программу ловить их всюду,


Под какой угрозой? Исключения обычно ловятся в очень малом количестве мест, как раз позволяя убрать мусор присутствующий без них на кодах возвратов.

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


Почему эта мифическая угроза заставляет ловить везде исключения, но при этом не заставляет проверять NaN-ы?
Re[4]: А идет ли развитие в области альтернатив исключениям?
От: _hum_ Беларусь  
Дата: 26.03.16 13:03
Оценка: 13 (1)
Здравствуйте, LaptevVV, Вы писали:

LVV>>>Тогда можно посмотреть в сторону инструмента — как это все реализовать.

LVV>>>ИМХО в этом случае аппарата исключений вполне достаточно.
LVV>>>А в системах реального времени — коды возврата (если средство разработки для этого подходящее)
__>>нет, дело именно в инструментарии, потому как иногда из-за его отсутствия приходится пересматривать понятие "аварийность" (когда обрабатывать некритические ошибки становится настолько громозко, что проще сделать их критическими с вызовом abort()")
LVV>А разве в С++ инструмент отсутствует?
LVV>Мне, например, исключений хватает за глаза.

а вы ссылку Evgeny.Panasyuk на выступление Александреску по этому поводу открывали? Хотя бы просто слайды гляньте: C++ and Beyond 2012: Andrei Alexandrescu &mdash; Systematic Error Handling in C++ &mdash; slides
в частности, слайд 11:

Exceptions are, [...]

• Slow on the exceptional path
• Hopelessly serial
— Only one exception in flight
— Requires immediate, exclusive attention
— Dedicated control flow
• Associated only with root reasons, not goals
— “I/O error” doesn’t describe “saving
weight file”

и вдобавок слайд 12

• Common complaint: “Error codes are limited!
Exceptions are arbitrarily rich!”

Re[6]: А идет ли развитие в области альтернатив исключениям?
От: _hum_ Беларусь  
Дата: 26.03.16 13:32
Оценка: :)
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


__>>мне нравится сама идея — возможность самому расширять любой тип значением undefined, чтобы замкнуть хотя бы какие-то операции


EP>Мне не нравится инфицирование всех выражений undefined'ом.


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

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

__>>>> a @ NaN -> NaN
__>>>> NaN @ NaN -> NaN
__>>>>(здесь @ — любая операция)
EP>>>Это аппликативный функтор, а не монада.
__>>а я думал, это что-то из разряда хаскелловской монады Maybe

EP>Каждая монада это аппликативный функтор, но не наоборот. Если использовать именно монадические свойства Maybe, например через Haskell'евский do-синтаксис, то на первом Nothing'е весь поток управления остановится, собственно для этого и происходит заворачивание в do-синтаксис, чтобы был контроль над потоком управления (что особенно видно если вручную расписать замыкания и bind'ы).


EP>Если же речь идёт про лифтование произвольных операций как в твоей табличке выше, то для этого достаточно аппликативного функтора.


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

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

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

EP>Их изначально именно и протаскивали ради императивных вещей, в частности таких как ввод-вывод.


да, но не так, чтобы повторить императивные вещи, а чтобы смоделировать императивность через функциональность (по крайней мере мне так казалось).

EP>Собственно исключения в Haskell именно как монада и реализованы.


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

1.1 Exception monad
[...]
There is an old dispute between C++ programmers on whether exceptions or error return codes are the right way. Also Niklaus Wirth considered exceptions to be the reincarnation of GOTO and thus omitted them in his languages. Haskell solves the problem a diplomatic way: Functions return error codes, but the handling of error codes does not uglify the calling code.


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


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


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


EP>Если речь идёт про Exception safety, то на C++ обычно всё что требуется для basic guarantee было бы и без исключений.


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

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


EP>Почему же во всех местах использования? Только в тех, где это критично.


ну, если вы где-то не поставите катч, то программа у вас повалится, даже если в том месте исключение не будет для вас критичным.

__>>тогда как в случае с аналогом NaN такой необходимости не будет.


EP>Если в каком-то месте критично чтобы вызов f() прошёл нормально, вернув нормальный результат, то и в случае с NaN'ами придётся городить проверки


да, но в том месте, где это некритично, проверки можно не ставить

__>>другими словами, ексепшены принуждают программиста под угрозой повалить программу ловить их всюду,


EP>Под какой угрозой? Исключения обычно ловятся в очень малом количестве мест, как раз позволяя убрать мусор присутствующий без них на кодах возвратов.


но вам их обязательно надо ловить! даже там, где вам это некритично.

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


EP>Почему эта мифическая угроза заставляет ловить везде исключения, но при этом не заставляет проверять NaN-ы?


if(1 == f())
{
   do_something();
}


в случае с "NaN" никаких доп. проверок делать не нужно. в случае с эксепшеном обязательно надо ставить трай-катч
Re[9]: А идет ли развитие в области альтернатив исключениям?
От: __kot2  
Дата: 26.03.16 13:50
Оценка:
Здравствуйте, netch80, Вы писали:
N>Мнэээ... подробнее, пожалуйста. Функция, насколько я помню, это отображение, которое для каждого прообраза из области определения даёт один и только один образ из области значений. Так?
N>И каким же образом это дополнение противоречит определению функции, если для f(x)=1/x
N>1) мы добавляем значения 0 и ∞ в обе области (определения и значения);
N>2) функция переводит их друг в друга;
N>3) значение функции для любого другого значения из ℝ этим не меняется
N>?
речь именно про две бесконечности. не может быть +∞ и -∞. только одна. иначе значение 1/x имеет два значения в нуле

N>А кто говорил про такую же линейную упорядочённость, и что она в этом случае должна сохраняться? Естественно, я не требую её сохранения (в том же виде) в случае включения ∞.

ну то есть устроит отстусвие непрерывности элементарных ф-ий и их дифференцируемости? а зачем вам вообще такие числа?

N>Не вижу никаких причин утверждать про "удобнее", тем более "в сто раз", и вижу противоположные тенденции, как на своём опыте, так и на опыте всей отрасли (выражающемся в создании значений типа NULL и NaN, возврате -1 по ошибке, и т.п.).

я и говорю, школота отокует

N>И пример с bool некорректен, если вспомнить fuzzy logic (нечёткую логику) и её признаки вероятности какого-то значения.

ну то есть устроит, если вдруг стандартный bool начнет возвращать вдруг true или false там с некоторыми раскладами?
Re[7]: А идет ли развитие в области альтернатив исключениям?
От: __kot2  
Дата: 26.03.16 13:54
Оценка:
Здравствуйте, _hum_, Вы писали:
EP>>Почему эта мифическая угроза заставляет ловить везде исключения, но при этом не заставляет проверять NaN-ы?
__>
__>if(1 == f())
__>{
__>   do_something();
__>}
__>

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

а в таком случае?

if(f() > 0)
   do_something();
else
   do_something2();


удобно сразу стало, да, иметь Nan ?

если вы допускаете Nan, то, например, даже две корректные реализации поиска максимального элемента массива могут дать разные результаты. вам нужны nan-proof версии всего когда, использующего сравнения < >

то же самое с сортировками

при введении Nan вы либо откалываетесь от всех сравнений <, либо пишете проверку на nan перед каждым таким сравнением. стало сразу удобно, да? только школьник-жапоскриптер может испытывать удобства от наличия Nan, ваяя свой спагетти говнокод
Отредактировано 26.03.2016 14:12 __kot2 . Предыдущая версия .
Re[5]: А идет ли развитие в области альтернатив исключениям?
От: LaptevVV Россия  
Дата: 26.03.16 14:07
Оценка: +1
Спасибо.
Ну, мне, например, понятно, что с развитием параллельного программирования надо с исключениями что-то делать.
Но, например, "медленность" их обработки — это фигня-вопрос.
Когда исключение возникает — тут уже не до скорости, тут авария.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[6]: А идет ли развитие в области альтернатив исключениям?
От: BulatZiganshin  
Дата: 26.03.16 14:25
Оценка: +2
Здравствуйте, LaptevVV, Вы писали:

LVV>Ну, мне, например, понятно, что с развитием параллельного программирования надо с исключениями что-то делать.

LVV>Но, например, "медленность" их обработки — это фигня-вопрос.
LVV>Когда исключение возникает — тут уже не до скорости, тут авария.

представь себе что скажем ты на gpu обрабатываешь триллион точек в секунду. и те точки у которых с данными что-то не срослось — надо просто игнорировать. какие уж там исключения, даже на if'ы времени не хватит...
Люди, я люблю вас! Будьте бдительны!!!
Re[8]: А идет ли развитие в области альтернатив исключениям?
От: BulatZiganshin  
Дата: 26.03.16 14:26
Оценка: -1
Здравствуйте, __kot2, Вы писали:

__>при введении Nan вы либо откалываетесь от всех сравнений <, либо пишете проверку на nan перед каждым таким сравнением. стало сразу удобно, да? только школьник-жапоскриптер может испытывать удобства от наличия Nan, ваяя свой спагетти говнокод


тссс, главное ему не говорите, что у чисел в компе ограниченная точность, а то профессора апоклепсический удар хватит
Люди, я люблю вас! Будьте бдительны!!!
Re[5]: А идет ли развитие в области альтернатив исключениям?
От: BulatZiganshin  
Дата: 26.03.16 14:32
Оценка:
Здравствуйте, _hum_, Вы писали:

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


монады — это как раз математическая концепция, позволяющая описывать побочные эффекты. т.е. пишешь ты x+y, а x/y могут быть null или future или вообще списком
Люди, я люблю вас! Будьте бдительны!!!
Re[8]: А идет ли развитие в области альтернатив исключениям?
От: _hum_ Беларусь  
Дата: 26.03.16 14:42
Оценка:
Здравствуйте, __kot2, Вы писали:

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

EP>>>Почему эта мифическая угроза заставляет ловить везде исключения, но при этом не заставляет проверять NaN-ы?
__>>
__>>if(1 == f())
__>>{
__>>   do_something();
__>>}
__>>

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

__>а в таком случае?


__>
__>if(f() > 0)
__>   do_something();
__>else
__>   do_something2();

__>


__>удобно сразу стало, да, иметь Nan ?


речь не о самом сыром float-NaN, а об идее. а в ней можно ограничить число операторов, которые могу использоваться со значениями "нан"-расширенного типа.
например, в приведенном коде функция бы имела декларацию extended_t<float> f(); и компилятор обязан был бы выдать ошибку в месте, где выполняется сравнение f() > 0, ибо эта операция не определена для расширенного типа.
Re[6]: А идет ли развитие в области альтернатив исключениям?
От: _hum_ Беларусь  
Дата: 26.03.16 14:48
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

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


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


BZ>монады — это как раз математическая концепция, позволяющая описывать побочные эффекты. т.е. пишешь ты x+y, а x/y могут быть null или future или вообще списком


описывать (моделировать), а не повторять.
Re[10]: А идет ли развитие в области альтернатив исключениям?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 26.03.16 15:00
Оценка:
Здравствуйте, __kot2, Вы писали:

__>речь именно про две бесконечности. не может быть +∞ и -∞. только одна. иначе значение 1/x имеет два значения в нуле


Да, одна. В интерпретации числовой окружности — именно так.
В компьютере — нет, потому что там +0 отличается от -0 (что принципиально в небольшом количестве интересных случаев).

N>>А кто говорил про такую же линейную упорядочённость, и что она в этом случае должна сохраняться? Естественно, я не требую её сохранения (в том же виде) в случае включения ∞.

__>ну то есть устроит отстусвие непрерывности элементарных ф-ий и их дифференцируемости?

О. Так речь шла вообще о функциях или о непрерывности и дифференцируемости?

__> а зачем вам вообще такие числа?


Тут уже упоминали ТФКП. Советую повторить.
Мне они такие не нужны, а вот INF компьютерное как отображение ситуации "тут был зашкал порядка" — нужен. И не надо его сводить до актуальной бесконечности, INF покрывает более широкий набор случаев.

__>я и говорю, школота отокует


Как удобно всё, чего не понимаешь, объявить целями школоты.

N>>И пример с bool некорректен, если вспомнить fuzzy logic (нечёткую логику) и её признаки вероятности какого-то значения.

__>ну то есть устроит, если вдруг стандартный bool начнет возвращать вдруг true или false там с некоторыми раскладами?

Стандартный — нет. Он уже ограничен. Но если бы не был ограничен, то вполне можно было бы использовать.
The God is real, unless declared integer.
Re[7]: А идет ли развитие в области альтернатив исключениям?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 26.03.16 15:02
Оценка: 4 (1)
Здравствуйте, _hum_, Вы писали:

N>>Придерусь — не NaN, а Inf. Это разные значения. В остальном согласен.

__>ого. не знал, что они ввели еще и бесконечности. здорово. только почему-то не нахожу инфу по их поведению (предполагаею, что наверное полностью соответствующее математическому определению + выход в qNaN в случае математической неопределенности. так?)

В общем да, но есть тонкости. Можете почитать final draft, он открыто выложен.
The God is real, unless declared integer.
Re: А идет ли развитие в области альтернатив исключениям?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 26.03.16 15:20
Оценка:
Здравствуйте, _hum_, Вы писали:

__>Нет ли каких-нибудь подходов хотя бы с облегчением передачи и унификацией кодов возвратов, например?


Возможно частично проблему исключений могут решить сопрограммы. В этом случае ошибочное состояние будет храниться как результат в одной из сопрогрограмм, где оно возникло.
Re[7]: А идет ли развитие в области альтернатив исключениям?
От: Evgeny.Panasyuk Россия  
Дата: 26.03.16 17:16
Оценка:
Здравствуйте, _hum_, Вы писали:

__>>>мне нравится сама идея — возможность самому расширять любой тип значением undefined, чтобы замкнуть хотя бы какие-то операции

EP>>Мне не нравится инфицирование всех выражений undefined'ом.
__>почему "всех"? можно же дать программисту возможность выбора, в каких операциях может участвовать расширенный тип, а в каких нет (и на этапе компиляции это отслеживать).

Всех в цепочке вычислений.

EP>>Их изначально именно и протаскивали ради императивных вещей, в частности таких как ввод-вывод.

__>да, но не так, чтобы повторить императивные вещи, а чтобы смоделировать императивность через функциональность (по крайней мере мне так казалось).

Повторять в каком смысле? В плане реализации — нет, там не повторение, а усложнение — нарезание всего кода на трёхэтажные замыкания. А вот по форме, в том числе и в случае с монадой Exceptional — очень и очень близко.

EP>>Собственно исключения в Haskell именно как монада и реализованы.

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

Именно меняет поток выполнения, прерывая его до первого catch, и именно так как в императивном языке.
И именно для того и нужны монады, чтобы управлять потоком выполнения.

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

EP>>Почему же во всех местах использования? Только в тех, где это критично.
__>ну, если вы где-то не поставите катч, то программа у вас повалится,

Что значит "повалится"?

__>даже если в том месте исключение не будет для вас критичным.


Так смысл исключений как раз в том, что их нельзя проигнорировать, и это правильный подход по-умолчанию. Когда же легко игнорировать, например при кодах возврата — то их систематически игнорируют
Автор: MTD
Дата: 21.02.13
.

__>>>тогда как в случае с аналогом NaN такой необходимости не будет.

EP>>Если в каком-то месте критично чтобы вызов f() прошёл нормально, вернув нормальный результат, то и в случае с NaN'ами придётся городить проверки
__>да, но в том месте, где это некритично, проверки можно не ставить

Там где некритично — пусть оно летит наверх по стэку.

__>>>другими словами, ексепшены принуждают программиста под угрозой повалить программу ловить их всюду,

EP>>Под какой угрозой? Исключения обычно ловятся в очень малом количестве мест, как раз позволяя убрать мусор присутствующий без них на кодах возвратов.
__>но вам их обязательно надо ловить!

Не вижу в этом проблемы — поставь catch наверху стэка

__>даже там, где вам это некритично.


Дай определение "некритично".

__>
__>if(1 == f())
__>{
__>   do_something();
__>}
__>

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

Обычно нужно обрабатывать все граничные варианты.
И не вижу проблемы с try-catch для случаев явного игнорирования, так как это очень редкий случай.
Я вот вообще не припомню вот такой код:
try{ action1(); } catch(...){ /*ignore*/ }
try{ action2(); } catch(...){ /*ignore*/ }
try{ action3(); } catch(...){ /*ignore*/ }
Re: А идет ли развитие в области альтернатив исключениям?
От: kov_serg Россия  
Дата: 26.03.16 17:21
Оценка:
Здравствуйте, _hum_, Вы писали:

__>В с++ в направлении усовершенствования исключений идет заметное движение. А как вообще в мире и в с++ в частности обстоит дело с развитием альтернатив исключениям (теми же кодами возвратов ошибок)?

__>Нет ли каких-нибудь подходов хотя бы с облегчением передачи и унификацией кодов возвратов, например? Или каких-нибудь замыканий (монад?), наподобие добавления к множеству возможных числовых результатов операций значения NaN, которое выводит деление на нуль из области исключительных ситуаций, и тем самым позволяет избавиться от уймы проверок на промежуточных этапах?

Вот подход, облегчающий жизнь, который позволяет избавиться от уймы проверок
http://reactivex.io/
Re[6]: А идет ли развитие в области альтернатив исключениям?
От: Evgeny.Panasyuk Россия  
Дата: 26.03.16 17:36
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>монады — это как раз математическая концепция, позволяющая описывать побочные эффекты. т.е. пишешь ты x+y, а x/y могут быть null или future или вообще списком


Для подобного лифтования операторов монады не нужны, достаточно аппликативного функтора.
Монады нужны именно для описания последовательности действий и контроля над потоком выполнения.
Re[2]: А идет ли развитие в области альтернатив исключениям?
От: uncommon Ниоткуда  
Дата: 27.03.16 05:01
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Есть некий симбиоз возвращаемых значений и исключений — expected&lt;T&gt;


Товарищ Александреску опять по своему обыкновению придумал фигню, которую никто никогда не будет использовать. Даже он сам. Expected<T> завязан на make_exception_ptr:

// Building from exception
// © 2012- Andrei Alexandrescu. Do not redistribute. 23 / 54
template
<class E>
static Expected<T> fromException(const E& exception) {
  if (typeid(exception) != typeid(E)) {
    throw std::invalid_argument( "slicing detected");
  }
  return fromException(std::make_exception_ptr(exception));
}


А make_exception_ptr как реализован?

166│   /// Obtain an exception_ptr pointing to a copy of the supplied object.
167│   template<typename _Ex>
168│     exception_ptr
169│     make_exception_ptr(_Ex __ex) _GLIBCXX_USE_NOEXCEPT
170│     {
171│ #if __cpp_exceptions
172│       try
173│         {
174├>          throw __ex;
175│         }
176│       catch(...)
177│         {
178│           return current_exception();
179│         }
180│ #else
181│       return exception_ptr();
182│ #endif
183│     }


То бишь, проще и более эффективно просто сразу выбросить исключение и не заморачиваться с Expected<T>, который внутри себя бросает, а потом ловит исключение, с одной единственной целью, как он сам говорит: избежать выброса исключения, потому что это очень дорогая операция.
Отредактировано 27.03.2016 5:03 uncommon . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.