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

Ок, тогда расскажи, как будешь реагировать на ESC пользователя, откатывая рабочий цикл с сотней объектов на стеке.

Среди которых объект интерфейса по UART, имеющий ещё три объекта-нитки приёма-передачи, объект-логгер, связанный ещё с двумя объектами-журналами в файл и консоль, и восемь десятков – приблизительно, хрен их там знает, сколько понадобится – OLE-проксей к внешним приложениям Оффиса, представляющим документы, параграфы, списки, стили, таблицы, книги, листы/ячейки/колонки и сами приложения, а также десяток std::коллекций с инфой оттуда и туда, а ещё сикось-накось связанной с тудой и оттудовой.

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

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

OpenGL, наверное можно было не прямые цитаты давать, а отвечать на посты Кили его же постами :)

Но вообще если серьезно, то времени не так и мало прошло, человек мог поменять мнение.

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

А чего бояться? Боятся что исключение их укусит? Или они просто матерые сишники, которые по привычке в придачу пишут все в одном классе, не используют наследование, и все методы у них статические, и то! Только из за того, что в C# нельзя написать функцию вне класса? Может им на пенсию пора?

Боятся, что исключение не будет обработано и это приведет к крэшу

А это что плохо? Если у тебя произошло исключение - это значит код, который его кинул - не смог справится с ошибкой. Коды возврата тебе тут не помогут. Если ты боишься что где то не обработаешь исключение, то почему ты не боишься того, что где то ты не проверишь возвращаемое значение? И все равно это приведет к крэшу, и хорошо - если к крэшу, так хоть упало - и сразу все понятно. А если будет не крэшь а произойдет операция - которая в принципе не должна произойти? По моему это хуже крэша. ... С кодами возврата можно отгребсти куда больше проблем. И таких ошибок, что catch(...) тебе сказкой покажется. Там хоть бряк можно поставить, и сразу туда вылететь в этот catch.

Это плохо, но не смертельно. А вот когда у тебя программа работает с некорректными данными, а ты еще об этом даже не догадываешься - вот тут будет полнейшая жопа. Ты просто можешь реально влететь в такую жопу. Что потом забудешь return, и будешь вместо него везде писать throw.

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

Я разве не говорил, что на WinAPI легко писать отказоустойчивый код, а на POSIX это в принципе невозможно? И всё потому, что SEH не языковой механизм.

Разве что goto писать не нужно, но __try нужно, и __finally не забыть, и не забыть очистить все ресурсы.

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

RAII хороший в С++, в Сях все равно это преврящается в ручной вызов функции очистки.

Сях все равно это преврящается в ручной вызов функции очистки. Я то говорил в контексте Си, а не С++.

Я написал потенциальной утечкой. Если ты задумал вручную чистить ресурсы, то можно и с исключениями обойтись без. RAII, чисти все в catch или если есть finally то в нем, в D можно чистить в scope(exit). RAII это всего лишь способ избежать ручной чистки, применять его удобно и для исключений и для ранних return'ов.

Хотя,ЕМНИП в Java нужно явно перечислять все виды исключений, которые может бросить функция. Поправьте, если я ошибаюсь.

Киля, не бомби. Я, конечно, добрый, но тут есть и другие модеры.

Ну если развить эту тему, то современные IDE при наведении мыши краткий кусок из доков выводят, где написано, что именно кидает функция, ну и доки ща модно прямо в комментах писать, так что go to declaration. и читай на здоровье.

Ты отмазался общими словами

Ну вот я тебе привел выше пример, когда забивание на bad_alloc, приведет к по сути багу.

Но как видим, Киля типа подразумевал под этим что-то другое.

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

Я даже примеры приводил, когда один и тот же bad_alloc в разных контекстах может быть как ожидаемым (и значит его вполне можно поймать и обработать), так и неожиданным (и тогда на него просто в данный момент забиваем).

Попробуй перечитать ещё раз то, на что ты отвечаешь.

Не надо врать. Я говорил, что надо перехватывать то, что ты можешь обработать вот здесь и сейчас. В твоём сценарии ты, несмотря на ошибку, можешь вернуть в js что-то удобоваримое? Тогда это тот случай, когда его надо перехватить, только и всего.

Возьми например абстрактно посмотри на сигнатуру функции: bool is_open();
Да мне ничего не нужно делать, чтоб понять какие ошибки эта функция может возвратить. либо true, либо false.

Ты мне тут несколько страниц чесал, что тебе плевать на исключение, если ты его пропустишь

Что ты хотел сказать-то своим is_open?