В этой статье дается хороший обзор о том, почему структурированная обработка исключений является плохим. Есть ли способ повысить надежность остановки вашего сервера от сбоев, преодолев проблемы, упомянутые в статье?
У меня есть серверное программное обеспечение, которое одновременно запускает около 400 подключенных пользователей. Но если произошел сбой, затронуты все 400 пользователей. Мы добавили структурированную обработку исключений и некоторое время наслаждались результатами, но в конечном итоге пришлось удалить ее из-за некоторых сбоев, вызывающих зависание всего сервера (что хуже, чем просто сбой и перезапуск).
Итак, мы имеем это:
Разбейте свою программу на рабочие процессы и на один серверный процесс. Процесс сервера обрабатывает начальные запросы, а затем передает их рабочим процессам. Если рабочий процесс выходит из строя, затрагиваются только пользователи этого рабочего. Не используйте SEH для общей обработки исключений - как вы выяснили, он может и оставит вас широко открытыми до тупиков, и вы все равно можете все равно сработать.
Использование SEH, потому что ваша программа случайно падает, это плохая идея. Это не волшебная пыль пикселов, которую вы можете посыпать своей программой, чтобы она перестала рушиться. Отслеживание и исправление ошибок, которые вызывают сбои, является правильным решением.
Использование SEH, когда вам действительно нужно обрабатывать структурированное исключение, прекрасно. Ларри Остерман сделал следующее сообщение, объяснив какие ситуации требуют SEH: файлы с отображением памяти, RPC и переходы границы безопасности.
Исправить ошибки в вашей программе?;)
Лично я бы сохранил обработчики SEH, чтобы они выгрузили стек вызовов, где было нарушение прав доступа или что-то еще, и устранили проблемы. Вероятность "иногда зависания сервера", вероятно, связана с взаимоблокировками, вызванными потоком, который имеет исключение SEH, которое сохраняет что-то заблокированное и поэтому вряд ли будет связано с тем фактом, что вы используете сам SEH.