LINUX.ORG.RU

java - let it crash?

 


1

1

Кто-нибудь пробовал кодить на Java в стиле let it crash? Какие подводные камни?

Есть какие-нибудь готовые фреймворки/гипервизоры итп? (прозреваю, какой-то набор примитивов для программирования внутри vm, в т.ч. специальные примитивы многопточности. Возможно понадобится пачка пред-прогретых java-машин, общающихся через какой-нибудь бинарный протокол, и поддерживаемых гипервизором. Плюс )

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

Интересна именно сама Java8 SE, а не scala+akka итп

Для тех кто не в теме: суть в неиспользовании defensive programming. Нить упала? Да и черт бы с ней! Не надо пытаться отловить ошибки и нормализовать выполнение. Убиваем ее и запускаем заново. Память не может быть read? По сети пришло не то? Руководитель - наркоман, а тимлидер - макдак? Let it crash!

Автобусы опаздывают? Экстерминатус. Ваш начальник отказывается повысить зарплату? Экстерминатус. Бывшая жена вас достает? Экстерминатус. Существует ли проблема, которую нельзя разрешить Экстерминатусом? Я такой пока не нашел.

— Инквизитор Лорд Котеас

★★★★☆

Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от Deleted

Ну смотри, приходит массив таких записей. Задача работает-работает, доходит до битой записи, потом падает, и запускается заново. А там опять приходит битая запись и задача опять падает. И так пока retry count не выйдет. Что это даст? Не понятно. Тут лучше делать defensive программирование, ожидать, что любого поля может не быть, если нет какого-то необходимого поля, то срать в лог и пропускать запись.

dizza ★★★★★
()
Ответ на: комментарий от dizza

приходит массив таких записей

дальше не читал, потому что ты шкалофаг и читать то не умеешь:

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

Deleted
()
Ответ на: комментарий от Deleted

Ок, да хоть и каждое сообщение в отдельной задаче. Принципа это не меняет. Задача будет непонятно зачем пытаться выполниться несколько раз. Let it crash хорошо работает, когда есть только временные проблемы типа истощения ресурсов, постоянные проблемы вроде багов нужно фиксить. В случае интеграции баги внешних систем фиксить не всегда реально.

dizza ★★★★★
()
Ответ на: комментарий от dizza

Задача будет непонятно зачем пытаться выполниться несколько раз.

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

Deleted
()
Ответ на: комментарий от Deleted

Правльно, фейлить пакет данных. Но это уже как раз выбивается из концепции let it crash - do not use defensive programming. А валидация пакета это как раз defensive programming.

dizza ★★★★★
()
Ответ на: комментарий от dizza

А валидация пакета это как раз defensive programming.

Тебя кудато несет, не валидация, а ошибка при разборе - это разные вещи.

Deleted
()
Ответ на: комментарий от anonymous

На жабе таки довольно легко изобразить подобную конструкцию.

anonymous
()
Ответ на: комментарий от dizza

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

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

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

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

anonymous
()
Ответ на: комментарий от anonymous

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

ckotinko ☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.