Comments 20
services:
...
restart: always/fixed
А если серьезно - даже без докера, и в Windows, и в Linux есть встроенные средства для перезапуска упавшего процесса.
except вместе с pass всегда требует комментария, почему исключения игнорируются.
Вы имели виду по коду... ну в данном случае там возникало сравнение с None. Можно обработчик поставить, а можно просто обработать ошибку и прекратить выполнение. Результат одинаков.
этот блок try-except охватывает большое количество кода, там не только "возникало сравнение с None" (которое надо делать явно) но и куча других исключений может быть, но про них никогда не узнаем, потому они все замалчиваются.
куча других исключений может быть, но про них никогда не узнаем, потому они все замалчиваются
Если прочитать статью то создаётся впечателение, что именно этот подход её и родил )). Вот, приведу цитату
Но вот незадача... Вроде бы весь код отлажен, работа приложения стабильна, но в какие‑то моменты замечается, что «бах» и процесс пропал. Ни ошибки в логах, ни сигналов, ничего нет. И как ловить, не очень понятно
Почему же в логах нет ошибок, как же так могло получиться ))
Да и есть ли сами логи? Даже при отсутствии информации об ошибках просто грамотное логирование часто может помочь найти место, где код падает. Когда знаешь, что по коду за такой-то операцией должна идти такая-то, а лог именно в этом месте прерывается.
В оригинальном приложении, из которого родилась эта частная задача, производилось соединение и запрос к источнику данных, источник данных возвращал положительный код ответа, но какую-то иногда выплёвывал чушь, хотя не должен был. Отправитель считал, что он отправил всё корректно. При этом эта чушь даже по структуре была разная, какими-то странными символами и прочее. Мы обратились к производителю и не смогли добиться внятного ответа, ушёл в молчание (видимо сам анализирует проблему). Наше приложение не могло идентифицировать эту разнообразную чушь и падало. Мы сначала писали кучу обработчиков, но тщетно... вот пришли к такому решению. Видимо не понравилось оно сообществу. Один хейт в комментариях.
Вообще, если приложению приходит чушь, оно должно кидать и ловить эксепшены. На каких-то уровнях приложения эксепшены должны ловиться и обрабатываться - запись в логи и воостановление процессов должны быть в обработчике. А вы, видимо, на произвол судьбы всё бросаете, вот и результат.
Как-будто вообще не вниклив суть. Стороннее приложение отправляет чушь.
И что? Почему на вашей то стороне вы не можете исключение поймать, обработать и сделать повторный запрос?
Ну потому что приходит код, как будто все норм, а по факту, нет. Когда разбирать начинаем, то летит ... нужно кучу обработчик писать. Зачем?
Зачем кучу то? Достаточно повесить ловлю исключения на самом верхнем уровне, где вы можете каким-то образом продолжить обработку. Если это невозможно в вашем коде (он у вас "сильно связанный" либо вообще "спагетти-код"), то самое время подумать над рефакторингом. Модульность должна быть. Какая-то проблема где-то нам на нижнем уровне не должна рушить сразу весь код снизу до верху. Она должна рушить работу только одного модуля, работу которого должен уметь восстановить либо инициировать заново модуль/класс выше по иерархии.
Наше приложение не могло идентифицировать эту разнообразную чушь и падало. Мы сначала писали кучу обработчиков, но тщетно... вот пришли к такому решению.
Ну по идее надо сделать один обработчик на методе получения данных. Или там данные, которые пришли снаружи, могли привести к ошибке в непредсказуемый момент? Тогда я бы стал логать данные и также сделал общий обработчик, который пишет в логи стектерйс эксепшна.
Игнорировать исключения - неправильно, надо их хотя бы логгировать. Я лично в своём пет проекте пару дней назад словил неприятностей, потому что заигнорил исключения. Казалось, там вооще ничего не могло пойти не так. А надо было логгировать, времени это бы мне сэкономило серьёзно.
Видимо не понравилось оно сообществу. Один хейт в комментариях.
Хейт не из-за того, что ваше решение не понравилось, а из-за того, что вы не использовали стандартные решения. Мне ваша статья понравилась, я её плюсанул. Для меня наличие стандартного решения - не повод не рассказать о велосипеде.
Комментарий у меня ехидный получился, конечно ((( . Примите как дружескую подколку. Как я понял суть вашей статьи в том, как манипулировать процессами с помощью питона, а не в том, как писать идеальный код ))
Может быть если бы вы написали, что можно было решить проблему по другому, но вы выбрали именно свой вариант - минусов было бы меньше. Но и комментариев было бы меньше ))
Не в результате дело (и не очевидно, что он один и тот же), а в явном объяснении своей логики там, где она не очевидна.
systemd?
Решение проблемы «падения» процессов в приложении, работающее 24/7 в режиме мультипроцессинга