Лучшая практика обработки исключений в службе Windows?

В настоящее время я пишу службу Windows, которая работает полностью в фоновом режиме и что-то делает каждый день. Моя идея заключается в том, что служба должна быть очень стабильной, поэтому, если что-то пойдет не так, она не должна останавливаться, но попробуйте на следующий день снова и, конечно, запишите исключение. Можете ли вы предложить мне наилучшую практику, как сделать действительно стабильные службы Windows?

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

Ответ 1

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

Ответ 2

Вопрос, который вы должны задать, заключается в том, что ваша служба Windows будет терпима к ошибкам. Помните, что любое необработанное исключение приведет к снижению обслуживания, что приводит к его немедленной недоступности. Как, по вашему мнению, ваша служба должна вести себя? Должен ли он попытаться и продолжать обслуживать все, что ему нужно? Должен ли он быть прерван?

Ответ 3

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

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

Ответ 4

Фактически, если у вас есть непредвиденное исключение, которое передается до самого верхнего уровня вашей службы, вы не должны продолжать обработку; запишите его и передайте его. Если вам действительно нужна "надежная" услуга, вам понадобится "сторожевой таймер", который перезапускает исходную услугу, когда она выйдет.

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

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

Последнее замечание: этот уровень надежности в сервисе редко необходим. В коммерческом коде я видел, как он использовался в нескольких антивирусных программах и программе сетевой фильтрации (которые должны были выполняться, иначе вся сетевая связь не удалась). Я сам сделал пару программ "сторожевого пса", но это было для клиентов, таких как автокомпании, которые потеряли бы тонн денег, когда их системы сборочных линий снизились. В дополнение к программному сторожевому устройству эти системы также имели избыточные источники питания, жесткие диски с горячей заменой RAIDed и полный дубликат всей системы для использования в качестве автоматического переключения на резервный ресурс.

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

Мой совет был бы во-первых, знать, какие исключения вы ловите и ловите их. Это будет более полезно для вас в будущем, если вы знаете, что вы ловите, а не общий (Exception e)

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

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

Как только вы узнаете об исключениях, о которых вы ранее не знали, их можно затем переустановить в следующую версию с более идеальным способом их обработки.