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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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