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

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

Так вот. Для того, чтоб донести месадж о катастрофе до человека, не надо пытаться судорожно что-то передавать и пытаться восстановиться. Достаточно помереть всей цепочке, а программа монитор (или watchdog) уже как-нибудь донесет эту мысль до человека, что СЭР, ВСЕ ПРОПАЛО. Потому что попытка восстановиться из проблемы, непосредственно с человеком не связанной и его вводом не вызванной, т.е. не ожидаемой проблемы - может по цепочке породить каскад новых проблем.


Иначе - это не про проблемы, а просто про штатные ситуации. Т.е. если пользователь сдергивает по http файл, а файла нет - это не проблемная ситуация ни разу, а как раз очень даже штатная (с т.з. сервера) - т.е. он, сервер, вполне себе в состоянии эту мысль пользователю донести, не перейдя в неопределенное состояние с требованием аварийного восстановления по finally и прочим catch.

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

iv_an_ruСпрашивается, что из перечисленного делает упомянутый рентгеновский аппарат?

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

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

iv_an_rusocimedВсе это и делает. Меняются только названия компонент и немного порядок действийВ таком случае вы всё правильно пишете: в вашей чуши надо только поменять слова и немного их порядок --- и спорить будет не о чем.

Человек, понаписавший свой valgrind дружественный аллокатор говорит мне о чуши? Да что за чушь!

softwarersocimedЕсть только одна обрабатываемая проблемная ситуация - это ввод человека.
В философском смысле любая ситуация - это ввод человека (прямой или косвенный). А в нормальном - это не так. Когда ты суёшь ногу в лифт и его дверцы, не закрывшись, открываются - это обработка проблемной ситуации.
С чего бы вдруг? Это как раз обработка пользовательского ввода. В данном случае - ввода ноги, буквально.
Ситуация, изначально заложенная в конструкцию лифта, и обрабатываемая как штатная, ни разу не исключительная.

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

И она исключает дальнейшую работу лифта, на то она и исключение.

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

softwarersocimedДля этого бросать exception вовсе не обязательно.
Не обязательно. Но иногда удобнее и разумнее, чем использовать какой-либо другой механизм.
Демагогия.

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

softwarer Возьми любой модуль, любой софт, который не обрабатывает некую проблему и должен по-твоему упасть в кору. Теперь я даю тебе задание: напиши автоматизированный тест для этого софта. Всё, получившийся продукт уже не должен падать в кору, он должен ставить галочку "тест пройден". Это иллюстрирует простой факт:
Это лишь иллюстрирует неумение тобой писать тесты. Галочки ставит не падающий компонент, а монитор (watchdog) следящий за этим компонентом. Упал порожденный процесс - галочка. Не упал - другая галочка.

softwarersocimedИначе - это не про проблемы, а просто про штатные ситуации.
В мире нет штатных и нештатных ситуаций. Есть только те, которые мы, с нашим мышлением, называем теми или другими.
Штатная ситуация - это прописанная человеком в документации к объекту.
Условия работы лифта и т.д.

А нештатная - это падение метеорита в лифт - ни в одной инструкции подобное не прописано, что метеорит может попасть.
Там лишь, в инструкции, нечто вида - "в случае внештаной ситуации делайте то-то", в нашем случае - выпадайте в кору, или ставьте распорки в лифте, чтоб не брякнуться об пол с высоты 20 этажа. Авось поможет, от метеорита-то.

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

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

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

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

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

Это и есть - отсутствие описания в руководстве обработки внештатной, исключительной ситуации, в части, а что делать после обрыва чтоб продолжать ездить вверх-вниз. А ничего не делать. Все. Оборвался тросс - core dump, жизненный цикл закончен.

softwarerВыключи трепло
Включи мозг

softwarerЗначит, у тебя бедная фантазия.
Это значит что у меня здравый рассудок, а нафантазировать можно чего угодно - даже гиппопотамов, летающий за счет реактивной струи из заднего прохода, проблема только в том, что подобная болезненная фантазия не дает им, гиппопотамам с реактивной струей, право на существование (хотя в мире ООП, конечно, законы физики не действуют, и позволено воплощать в граните любую сказочно глупую укатайку, что и происходит повсеместно - контроля то нет никакого).

ПрограмёрКстати, а какое отношение исключения имеют к ООП? Что-то тема уже ушла далеко)

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

softwarersocimedпропущено...

Непосредственное. К примеру в НЕ ООП языке C исключений нет как таковых.
Совсем демагогию погнал, одним совпадением обосновываешь связь. А к примеру в НЕ ООП языке PL/SQL они есть, и что?

И что? в PL/SQL и ООП есть по самое небалуйся, давно документацию читал?