socimedПроблема лишь в том, что в 99.9999% случаев ООП программист ни сном ни духом бросает исключение, и думает, что его там кто-то сверху его обработает и вообще там на верху в курсе, что в него сейчас прилетит ЭТО и знают как с этим справиться.


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

Вообщем тебе нужно чтото из азбуки почитать по Try-Catch обработкам.
Потому что они реально есть в той или иной степени в любом языке.

Короче я понял о чем говорит Грекс.
С точки зрения восстановления данных он прав, никто не занимается восстановлением данных в блоках Catch.
Это просто не имеет смысла в большинстве случаев. Обычно в Catch дается возможность попытаться понять и сообщить что произошло и прекратить дальнейшее выполнения цепочки действий.

Это правильно с точки зрения одной взятой компоненты. Но с точки зрения приложения - это неверно.

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

Тоесть с точки зрения отдельно взятой маленькой компоненты уйти в кор - это правильно.
С точки зрения сервера - в корне неверно.

Собственно так и работает ОСь, крах приложения с любой ошибкой ведет к смерти приложения но не ОСи.

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


Я тебе попытаюсь показать на пальцах.




Вот ты пытаешся апеллировать к вероятности в 0.0001%. Причем никак не рассказываешь как побороть оставшиеся 0.0001% случаев, а пытаешся убрать трай кетчи и просто лететь сразу в кор без логирования.

socimed,

С точки зрения Здания (Сервер) это штатная ситуация. Лифт оборвался, улетел вниз, ну и хрен с ним. Сообщили о инциденте и забыли. На работу отдела на первом этаже это почти никак не повлияет.
А ты пытаешся рассказать что обрыв лифта внутри здания ведет к выводу из строя всего Здания (Сервера).

Чтобы вывести из строя здание, нужно валить его пилоны, а єто уже совсем другая ситуация.
Также как и чтобы вывести из строя ОСь нужно валить ее ядро.

socimedКассирКороче я понял о чем говорит Грекс.
С точки зрения восстановления данных он прав, никто не занимается восстановлением данных в блоках Catch.
Это просто не имеет смысла в большинстве случаев. Обычно в Catch дается возможность попытаться понять и сообщить что произошло и прекратить дальнейшее выполнения цепочки действий.

Это правильно с точки зрения одной взятой компоненты. Но с точки зрения приложения - это неверно.

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

Тоесть с точки зрения отдельно взятой маленькой компоненты уйти в кор - это правильно.
С точки зрения сервера - в корне неверно.

Собственно так и работает ОСь, крах приложения с любой ошибкой ведет к смерти приложения но не ОСи.

Все верно, и вот тут самое время (получив хоть одного что-то понимающего) перейти к следущему циклу холивара - осознать, что любая система (отказоустойчивая) должна состоять:

- из независимых компонент, каждое из которых может падать в кору, не обваливая соседние
- компоненты общаются между собой специальными вызовами (marshalling, RPC, что угодно из отряда IPC, да хоть http-json)
- отдельно должен существовать компонент-монитор, который отслеживает состояние системы в целом и перезапускает компоненты, которые упали почему-то.


Если говорить про, допустим, веб сервер, то нам нужно иметь

- монитор (zabbix, systemd)
- компонент, который отвечает за поддержку очереди клиентов (nginx, haproxy, squid)
- компонент, который отвечает за логику приложения (apache, php)
- компонент, которых отвечает за базу данных (mysql)

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

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


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

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

Ура ура.

А то лифты, рентгены, азбуки. Ути пути. Глаза разуйте - все придумано и так до вас.

Ну ты сейчас кажешся немножечко идиотом.
Потому что пришел сюда под знамена "Долой Трай Кетч!"
А философия Трай Кетч как раз и построена на архитектуре разделения компонент.
И дается возможность вызывающему "перезапустить, обработать, залогировать" сбои в этой компоненты.

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


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

А ты пытаешся тут рассказать про вылеты в кор и бесполезности Трай Кетч не понимая,
что обьект класса это и есть контролиуемая компонета .
Потому что состояние ее инкапсулировано. И внешний вызывающий код просто обрабатывает ситуацию сбоя в этом обьекте.

socimedКак насчет того, что catch не сработает просто потому, что соседний безумный компонент напрочь разрушил память и твоего компонента тоже?

Ну реально, взял и протер рандомно память всех НЕ СВОИХ объектов (и твоих тоже), и что ты там будешь ловить в своих catch, чудо?


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

У тебя ситуация всё, приплыли, лифт не только сорвался и упал в шахту, он упал так, что пробил нафиг пол и попал и в магазин, и в офис, поубивав там человеков.


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