この記事では、構造化された例外処理がよくない理由について概要を説明しています。この記事で言及されている問題を回避しながら、サーバーのクラッシュを防ぐ堅牢性を確保する方法はありますか?
約 400 人の接続ユーザーを同時に実行するサーバー ソフトウェアがあります。しかし、クラッシュが発生した場合、400 人のユーザー全員が影響を受けます。構造化された例外処理を追加し、しばらくは結果を楽しみましたが、サーバー全体がハングするクラッシュが発生したため、最終的に削除する必要がありました (クラッシュして再起動するよりも悪いことです)。
だから私たちはこれを持っています：
プログラムがランダムにクラッシュするため、SEH を使用することはお勧めできません。クラッシュを止めるためにプログラムに振りかけるのは、魔法の妖精の粉ではありません。クラッシュの原因となっているバグを追跡して修正することが正しい解決策です。
構造化された例外を本当に処理する必要がある場合は、SEH を使用しても問題ありません。Larry Osterman は、どのような状況で SEH が必要になるかを説明するフォローアップ投稿を行いました: メモリ マップ ファイル、RPC、およびセキュリティ境界遷移.
プログラムをワーカー プロセスと単一のサーバー プロセスに分割します。サーバー プロセスは最初の要求を処理し、ワーカー プロセスに渡します。ワーカー プロセスがクラッシュした場合、そのワーカーのユーザーのみが影響を受けます。一般的な例外処理に SEH を使用しないでください。ご存知のように、SEH を使用すると、デッドロックが発生する可能性があり、そのままにしておく可能性があり、とにかくクラッシュする可能性があります。
プログラムのバグを修正しますか? ;)
個人的には、SEH ハンドラーを保持しておき、アクセス違反が発生した場所などのコール スタックをダンプして問題を修正するようにします。「サーバーがハングすることがある」という問題は、おそらく何かをロックしたままにしている SEH 例外が発生したスレッドによってデッドロックが発生したためであり、SEH 自体を使用しているという事実に関連している可能性は低いです。