Addxiv_an_ru,
если убрать "_Разумеется_, правильно заюзаное ООП даёт прирост скорости программе.",
то соглашусь :)
Удешевление разработки и сопровождения отнюдь не всегда положительно сказывается на расходы заказчика, и уж совсем не факт, что он вложит их в оборудование. )

Там был неприкрытый стёб.

Обработка ошибок даже с двумя десятками if (пациент тонко шутит на незнание оптимизации по switch/case типовым кодером) всегда будет раз в 10-200 быстрее, чем обработка исключений, просто из-за крайней неэффективности реализации этого самого механизма исключений.

Но типовой ООП программист этим не озадачивается и вовсю использует exception как форму goto XXI века.

iv_an_rusocimedОбработка ошибок даже с двумя десятками if (пациент тонко шутит на незнание оптимизации по switch/case типовым кодером) всегда будет раз в 10-200 быстрее, чем обработка исключений, просто из-за крайней неэффективности реализации этого самого механизма исключений.

Но типовой ООП программист этим не озадачивается и вовсю использует exception как форму goto XXI века.Вобще-то я про скорость кода, исполняемого в случае, когда ни одно исключение так и не вылетело. Нету if-ов --- нечему рвать конвейер ядра. Если ошибка таки приключилась --- тут уже один чорт не до скорости, тут лишь бы не посыпалось всё :)

Я говорил про то, что в мозгах ООП "программистов" замечен типовой сдвиг по фазе. Они путают exception с нелокальным goto, там даже не про вопрос ошибок, а просто вот так они делают setjmp/longjmp (которые редкий C программист в здравом уме вот просто так начнет использовать, в равной степени и ucontext/coroutine, просто по причине их сложности).

Но exception-goto для ООП-истов относительно дешев, вот там и процветает эта разновидность говнокодирования.


А вот обработка ошибок - это настолько отдельная тема, что тут можно смело начинать холивар на 100500 страниц.
В моем (и не только) понимании - единственно верная обработка ошибок - это упасть в core и выдать посмертный мессдж в syslog.
Все остальное - это не ошибка, а как раз разновидность данных, и эти все разновидности должна обрабатываться явно.

К примеру не ввел пользователь свое ФИО - это нифига не exception, это просто обычный поток кода, который завернет его "пользователя" обратно на поле ввода.

Ошибки - это нечто заранее не предусмотренное. А раз не предусмотренное, то причины явления не известны, и дальнейшее поведение ПО непредсказуемо, и может привести к еще большей порче данных. Потому самое безопасное тут - просто упасть и выдать программеру информацию где и на чем упали - пусть разбирается и пишет свои if-ы с обработкой.

Но в мире ООП это, конечно, не так.

iv_an_rusocimedВ моем (и не только) понимании - единственно верная обработка ошибок - это упасть в core и выдать посмертный мессдж в syslog.
Все остальное - это не ошибка, а как раз разновидность данных, и эти все разновидности должна обрабатываться явно.Явный обработчик на конкретную ошибку как раз подпадает под это правило. Это раз. Ну и падать в core не всегда полезно, общество может осудить. Особенно если ошибка --- сетевой затык с пакетом фигни для какого-то ящика у неоперативного персонала, а падение в корку будет сопровождаться голосом тёти Риты, сиреной, разбегательством людей из машзала во все стороны и аварийным остановом турбины.

Потеря пакета, разрыв соединения - это не ошибка, а штатное, обрабатываемое поведение. Должен существовать в явном виде код, который может с ней справиться, не приводя состояние системы в неопределенное.

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

softwarersocimedК примеру не ввел пользователь свое ФИО - это нифига не exception
Забавный пример к тезису "страшно долгий неэффективный exception"

Там нет никакой связи с "долготой". Ты читаешь криво. Тема из обсуждения тормознутости exception в сравнении с if вообще перешла в другое измерение - отделение понятия setjmp/longjump/exception, от понятия необрабатываемой ошибки, понятия обрабатываемой ошибки, и контроля входящих данных.

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

Александр, чем проявлять такое феерически глупое ослоумие, я тебе предлагаю сначала ознакомиться с требованиями к огранизации ПО в этой области.

Начни с MISRA .

Как только там найдешь что-то конкретное про с++ exception - ты обязательно сообщи, ок?

Вот к примеру тут http://www.appinf.com/download/SafetyCriticalC .pdf в части требований JSF и того, что именно разрешено в MISRA

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

И таких блоков там (по идее) должен стоять не один, а штуки четыре, причем абсолютно независимых. Странно, что тебе это не очевидно.

softwarersocimedПотеря пакета, разрыв соединения - это не ошибка, а штатное, обрабатываемое поведение. Должен существовать в явном виде код, который может с ней справиться,
И этот код в ряде случаев озаглавлен catch Потеря_Пакета_Или_Разрыв_Соединения.

И что? Это как-то гарантирует, что программа справится со всеми аварийными случаями в этом try/catch блоке?

Что вот тот бросивший exception кусок - не разрушит потихому память в объекте сокета, приведя к каскадному NullPointerException уже при попытке его закрытия, внутри этого catch?

Гарантия где?

iv_an_ruНет 100% гарантий, вестимо. Ошибка всегда возможна, это вопрос вероятности. Но в ряде случаев можно надеяться, что вероятность достаточно мала, чтобы не вылезти ни разу за срок эксплуатации :)

Для систем, связанных с жизнью людей подобная демагогия просто недопустима. И там есть вполне четкие требования к тому, как должна быть организована обработка ошибок, в части формальных требований к избежанию возможных side effect.

iv_an_rusocimed,

Я немножко в курсе. Чесслово. softwarer, предположу, тоже в курсе. А вот вы маленечко плаваете даже в таких вещах, как определение, что такое ошибка --- из ваших высказываний следует, что это что-то не предусмотренное разработчиком.

В курсе чего? Он ни сном не духом и дальше будет уверен, что для управления излучателем рентгеновского аппарата достаточно понаписать try/catch блок и это покроет 105% всех аварийных ситуаций.

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

Ошибка внешняя, которая явно является обрабатываемой - это просто частный случай входящих данных (по отношению к компоненту).

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

Просто никто не тестирует свой код на предмет, а что если. А ты попробуй повставлять вызов exception во всякие разные места, где ты вызываешь третьесторонние компоненты, да потестить - справится ли твоя база данных с этим, не приведет ли к разрушению данных и противоречивому состоянию системы в целом. Простейший случай - out of memory - может возникнуть вообще где угодно. И?

iv_an_rusocimedПросто никто не тестирует свой код на предмет, а что если.Не говорите за всех, а? Иначе как раз "феерически глупое ослоумие" и получается.

socimedА ты попробуй повставлять вызов exception во всякие разные места, где ты вызываешь третьесторонние компоненты, да потестить - справится ли твоя база данных с этим, не приведет ли к разрушению данных и противоречивому состоянию системы в целом. Простейший случай - out of memory - может возникнуть вообще где угодно. И?Вот в чём я уверен, так это в том, что в вызовах третьесторонних компонент у нас ошибок нет. По причине отсутствия третьесторонних компонент. Это раз. И на случай out of memory в любом приличном сервере БД _разумеется_ предусмотрена не просто абы какая обработка, а специальный аварийный режим, в котором часть операций запрещается, часть транзакций откатывается, но сервер выживает и крутится дальше.

как прикольно. специальный аварийный редим.

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

да неужели?


а третьей стороной является и glibc. и сама операционная система, потому твое утверждение про "у нас нет" выглядит просто невероятно смешно

iv_an_rusocimedя утверждаю, что ошибка это вообще все, что не предусмотрел разработчик.А вот Мейерс утверждает, что ошибка --- это когда программа делает не то, что пользователю разумно от неё ожидать. Пользователю. Про разработчика ни слова. Получаем две гипотезы: 1. Мейерсу надо учить букварь. 2. Вам надо учить букварь. Какую из них берём за рабочую?

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

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


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

iv_an_rusocimedи что, в блоках откатки транзакций совсем нет новых попыток выделить память в куче?Почему "попыток"? Вполне успешных выделений. Гарантированно успешных, потому что на этот случай есть специальный резерв памяти.
И кто гарантирует, что этого резерва хватит?


iv_an_rusocimedа третьей стороной является и glibc. и сама операционная система, потому твое утверждение про "у нас нет" выглядит просто невероятно смешноТретьей стороной является Солнце, как источник космических лучей, приводящих к сбросу битов в ОЗУ. Тоже источник ошибок. Но и используемая часть glibc и используемая часть OS и используемая память являются достаточно надёжными ;)

Достаточно? И что будет если разработчики втихую добавят еще один вариант errno в send/recv, которого вы не предусмотрели в обработчике?
А еще можно впомнить про memcpy/memmove и весьма веселый спор Торвальдса и Дрейпера, на предмет чинить или не чинить.

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

iv_an_rusocimedлюди в 95% случаев или просто идиоты, или ведут себя как идиотыАга. Один вы у нас иноплянетянин, в белом фраке.

Нет, я знаю, что я могу себя вести как идиот и обычно так себя и веду. Но я знаю это и умею с этим бороться, а вы - нет.

К примеру в отличие от тебя и softwarer при первом же упоминании про MISRA (когда мне пояснили что я идиот) я быстро ее скачал и попробовал изучить от и до (и продолжаю это делать), а не просто проигнориловал, напыщенно надув губки и сделав оценочное суждение, что как-же это так, как это меня такого с детства превозносимого умника только что ткнули носом в мое невежество - такого быть не может!

Или ты хочешь сказать, что вот сейчас взял и скачал MISRA? И не надо говорить, что вы про нее знали - поиском цитирование не дало совпадений - раз не знали, значит и не упоминали.

В этом и есть отличие, и что дает мне право перекочевать из 95% в 5% со временем, а вам - нет. Забавно, да?