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

в большинстве случаев возникновение исключения разрешается просто abort() процесса. как-то особого смысла городить какой-то огород и давать девелоперам строить логику тут нет

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

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

вы серьезно?

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

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

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

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

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

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

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

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

__>>вы серьезно?
K>А что ещё сделать? В широком смысле если у тебя, например, отвалилась база, то ты должен рассматривать это как обычный кейс.

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

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

__>>>в большинстве случаев возникновение исключения разрешается просто abort() процесса. как-то особого смысла городить какой-то огород и давать девелоперам строить логику тут нет
__>>вы серьезно?
K>А что ещё сделать? В широком смысле если у тебя, например, отвалилась база, то ты должен рассматривать это как обычный кейс.

Вот у меня сейчас, если отвалилась основная база, я должен начать кидать данные во временную локальную. Терять — нельзя. По подъёму связи с основной — вкачать в неё сложенное в локальной.
Хорош бы я был, если б по обрыву связи с основной допускал abort()...

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

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

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

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

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

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

__>>>>в большинстве случаев возникновение исключения разрешается просто abort() процесса. как-то особого смысла городить какой-то огород и давать девелоперам строить логику тут нет
__>>>вы серьезно?
K>>А что ещё сделать? В широком смысле если у тебя, например, отвалилась база, то ты должен рассматривать это как обычный кейс.
__>есть понятие "живучести системы", которое, как и в живой природе, означает, что организм не должен умирать даже при серьезных потерях, не говоря уже о насморке.

Сразу видно, кто пишет системы, а кто приложения.

Сервисы, наверное, где между ними...

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

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

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

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

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

выглядит страшнова-то.. а вот указанный boost::optional<T> уже "ближе", но все равно еще не то...

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

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

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

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

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

и в моем представлении монады — это именно подобие реализации механизма NaN.

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

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

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

int modulo(int x, int m, int* result)
{
   int err_code = -1;// unknown error

   if(m > 0)
   {
      *result = x % m;

       err_code = 0;// ok. no error
   };

   return err_code;
}

int main(void)
{
   int x;
   int m;

   std::cin>>x;
   std::cin>>m;

   int res;

   const int err_code = modulo(x, m, &res);

   if(0 == err_code)
   {
     std::cout<<res;
   }
   else
  {
    std::cout<<"error";
  };
}

вот я и интересуюсь, что приниципиально нового с тех пор придумали-то?

Здравствуйте, _hum_, Вы писали:
__>в этом случае даже если у вас произойдет деление на нуль, поток управления все равно продолжит течь, как ни в чем не бывало
производя мусор
Вася сделает проверку на Нан, Петя забудет. правильнее все-таки падать
это же классика — мусор на входе, мусор на выходе. например, 3d max только и загнулся, что модели ломал при сохранении. когда возникала проблема, он, вместо того, чтобы сразу упасть, продолжал работать, ломая модель и похеривая работу (иногда и за несколько дней) дизайнера, сохраняя мусор

Здравствуйте, _hum_, Вы писали:
__>вот я и интересуюсь, что приниципиально нового с тех пор придумали-то?
ну, коды ошибок это вообще наркомания
конечно лучше кинуть исключение

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

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

__>Здравствуйте, _hum_, Вы писали:
__>>в этом случае даже если у вас произойдет деление на нуль, поток управления все равно продолжит течь, как ни в чем не бывало
__>производя мусор

не мусор, а NaN значение в математике же тоже так сделали — положили a/0 равным oo (бесконечности), что упростило написание кучи математических текстов (вместо того, чтобы каждый раз в тексте оговаривать "кроме нуля").

__>Вася сделает проверку на Нан, Петя забудет. правильнее все-таки падать

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

Здравствуйте, _hum_, Вы писали:
__>не мусор, а NaN значение в математике же тоже так сделали — положили a/0 равным oo (бесконечности), что упростило написание кучи математических текстов (вместо того, чтобы каждый раз в тексте оговаривать "кроме нуля").
я мехмат закончил, это вы можете бабушке у подьезда заяснить, что a/0 равно бесконечности. в реальности конечно же ничего подобного в математике нет

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

вы наверное намекаете, что в "новых современных" языках программирования, типа жабоскрипта есть Nan? да есть, но такие языки часто спроектированы школьником-дурачком Петей для себя, чтобы ему было удобнее, а совсем не для того, чтобы работать быстро и надежно. удобно иметь Nan? удобно. но это в ущерб стиабильности работы. где нас это устраивает? в гуе, например, более-менее. хотя я бы предпочел все-таки в каком-то медицинском или финансовом гуе, чтобы инфа все-таки были или 100% корректной или никакой, а не "корректной, но не всегда"

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

__>Здравствуйте, _hum_, Вы писали:
__>>не мусор, а NaN значение в математике же тоже так сделали — положили a/0 равным oo (бесконечности), что упростило написание кучи математических текстов (вместо того, чтобы каждый раз в тексте оговаривать "кроме нуля").

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






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

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

__>вы наверное намекаете, что в "новых современных" языках программирования, типа жабоскрипта есть Nan? да есть, но такие языки часто спроектированы школьником-дурачком Петей для себя, чтобы ему было удобнее, а совсем не для того, чтобы работать быстро и надежно. удобно иметь Nan? удобно. но это в ущерб стиабильности работы. где нас это устраивает? в гуе, например, более-менее. хотя я бы предпочел все-таки в каком-то медицинском или финансовом гуе, чтобы инфа все-таки были или 100% корректной или никакой, а не "корректной, но не всегда"

я хочу подчеркнуть, что я лишь говорил о возможных вариантах, но не называл их идеальными

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

__>я мехмат закончил

вот и работал бы профи-математиком, а не дилетантом-программистом

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

https://en.wikipedia.org/wiki/IEEE_floating_point реализован во всех современных cpu/gpu

Здравствуйте, _hum_, Вы писали:
__>Image: f3951f298dd5dad1cf532ab7e6e7c5b9.png
__>
что это за картинка?
у математики много разделов. единственный раздел, который оперирует с бесконечностями это ТФКП, но там есть свои собственные заморочки и a там комплексная и на плоскости, поэтому минус бесконечности, например, есчли не ошибаюсь, нет

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

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

так что я понять не могу из какого раздела эта картинка. для решебника 8ого класса какой-то школы со своей программой?

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

нормальный софт должен делать abort() когда у тебя вдруг bool стал равен 2. ненормальный — может продолжать работать, пытаясь сохранить хорошую мину при плохой игре.
в случае же какого-то аппарата вентиляции легких или еще чего-то обычно ставят watchdog, который перезагружает софт при его падении или отсуствии отклика. или же можно переключиться на резервное устройство. может, текущее просто перегрелось. софт, который не падает и не виснет, а продолжает что-то там делать непонятное, неизвестное и малопредсказуемое, например, вдруг увеличивает или уменьшает скорости вентиляции в три раза, просто не нужен.

Здравствуйте, BulatZiganshin, Вы писали:
BZ>https://en.wikipedia.org/wiki/IEEE_floating_point реализован во всех современных cpu/gpu
я в курсе про этот Nan, я просто не считаю, что с ним нужно продолжать работать

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

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

Это очень древняя тема, например, программирование COM/DCOM.
Роджерсон Дейл: Основы COM; 6. HRESULT GUID, Реестр и другие детали

HRESULT

Во всех самолетах есть приборы, и самодельные самолеты — не исключение. Хотя в некоторых таких самолетах роль приборов играет компьютер с цветным графическим дисплеем (иногда даже «под» Windows NT), обычно ставят что-нибудь подешевле. Металлическая полоса, например, — простейший индикатор скорости. Чем быстрее Вы летите, тем сильнее она изгибается.

Хотя приборы и могут сообщить в деталях, что происходит с самолетом и отдельными системами, их основное назначение — предупреждать об опасности. На индикаторе скорости есть красная полоска, отмечающая слишком высокую (или низкую) скорость. Часто приборы снабжают аварийными лампочками и зуммерами.

У компонентов СОМ нет приборов. Вместо шкал или лампочек для сообщений о текущем состоянии дел они используют HRESULT. QueryInterface вращает HRESULT. И, как мы увидим в оставшейся части книги, большинство функций интерфейсов СОМ также возвращает HRESULT. Xoтя из названия HRESULT можно было бы заключить, что это описатель (handle) результата, на самом деле это не так. HRESULT — это 32-разрядное значение, разделенное на три поля. Значения полей, составляющих HRESULT поясняет рис. 6-1. Название возникло по историческим причинам; расшифровывайте его как «вот результат» (here's the, result), а не «описатель результата» (handle of result).

Определенные системой значения HRESULT содержатся в заголовочном файле Win32 WINERROR.H. В начале файла расположены коды ошибок Win32, так что его нужно пролистать, чтобы добраться до HRESULT похож на код ошибки Win32, но это не одно и то же, и смешивать их не следует.

Старший бит HRESULT, как показано на рис. 6-1, отмечает, успешно или нет выполнена функция. Это позволяет определить много кодов возврата и для успеха, и для неудачи. Последние 16 битов содержат собственно код возврата. Остальные 15 битов содержат дополнительную информацию о типе и источнике кода ошибки.

В табл. 6-1 приведены наиболее часто используемые коды. По соглашению в названиях успешных кодов возврата содержится S_, а в названиях кодов ошибок — Е_.

Таблица 6-1. Распространенные значения HRESULT
Название Значение
S_OK Функция отработала успешно. В некоторых случаях этот код также означает, что функция возвращает логическую истину. Значение S_OK равно 0.
NOERROR Тоже,что S_ОК.
S_FALSE Функция отработала успешно и возвращает логическую ложь. Значение S_FALSE равно 1.
E_UNEXPECTED Неожиданная ошибка.
E_NOTIMPL Метод не реализован.
E_NOINTERFACE Компонент не поддерживает запрашиваемый интерфейс. Возвращается QueryInterface.
E_OUTOFMEMORY Компонент не может выделить требуемый объем памяти.
E_FAIL Ошибка по неуказанной причине.

Обратите внимание, что значение S_FALSE равно 1, а значение S_OK — 0. Это противоречит обычной практике программирования на C/C++, где 0 — это ложь, а не 0 — истина. Поэтому при использовании HRESULT обязательно явно сравнивайте коды возврата с S_FALSE или S_OK.

Пятнадцать битов — с 30-го по 16-й — содержат идентификатор средства (facility). Он указывает, какая часть операционной системы выдает данный код возврата.

И так далее.