一部のリソースSetUnhandledExceptionFilter
では、 を使用して未処理の例外をキャッチする代わりにAddVectoredExceptionHandler
、すべての例外の通知を受け取ることができると示唆しているようです。
ただし、私が理解できる限り、ベクトル化されたハンドラーは、例外が処理されるかどうか、またはどこで処理されるかを決定する前に、プログラムで発生したすべての(SEH) 例外に対して「ちょうど」呼び出されます。
何か不足していますか?
一部のリソースSetUnhandledExceptionFilter
では、 を使用して未処理の例外をキャッチする代わりにAddVectoredExceptionHandler
、すべての例外の通知を受け取ることができると示唆しているようです。
ただし、私が理解できる限り、ベクトル化されたハンドラーは、例外が処理されるかどうか、またはどこで処理されるかを決定する前に、プログラムで発生したすべての(SEH) 例外に対して「ちょうど」呼び出されます。
何か不足していますか?
良いコメント:
[代替品] ではありません。コールバックは、例外が処理されることについて何も約束しません。それは後で起こります。せいぜい、try/catch-em-all ステートメントが多すぎるプログラムの問題をトラブルシューティングするための診断ツールとして役立ちます。AVEH を必要とする種類の機能である .NET AppDomain.FirstChanceException イベントと比較してください。
– ハンス・パッサン
そうは言っても-そして私が同意するドキュメントを読み直した後-「混乱」は、私がリンクした元の質問で、述べた元の質問に起因する可能性があると思います
プロセスで発生するすべてのアクセス違反の例外をキャッチして適切に処理する必要があります
もちろん、ベクトル化された例外ハンドラーを使用することもできます。つまり、VEH を介してすべてをインターセプト0xC0000005
することもできますが、この周りのコードが実際にそれをキャッチして処理できるかどうかはわかりません。特定のケースでは、アクセス違反をキャッチし、キャッチ サイトで続行することが有効なアプローチです。
したがって、ハンスが言うように、それはせいぜい、診断ツールとして有用です.
または、別の言い方をすれば、ベクトル化された例外ハンドラーは、例外を「キャッチする」という意味で解釈し、発生した例外をより高いレベルでキャッチする場合、例外をキャッチしません。catch
__except
VectoredHandler
のみがサポートされています:EXCEPTION_CONTINUE_SEARCH
ハンドラーを見つけます:EXCEPTION_CONTINUE_EXECUTION
私が完全に把握したことのない使い方。