Application.UnhandledException イベント
定義
重要
一部の情報は、リリース前に大きく変更される可能性があるプレリリースされた製品に関するものです。 Microsoft は、ここに記載されている情報について、明示または黙示を問わず、一切保証しません。
ネイティブ レベルのWindows ランタイム エラーから転送された例外をアプリ コードで処理できる場合に発生します。 アプリは、イベント データで処理済みとしてオカレンスをマークできます。
public:
virtual event UnhandledExceptionEventHandler ^ UnhandledException;// Register
event_token UnhandledException(UnhandledExceptionEventHandler const& handler) const;
// Revoke with event_token
void UnhandledException(event_token const* cookie) const;
// Revoke with event_revoker
Application::UnhandledException_revoker UnhandledException(auto_revoke_t, UnhandledExceptionEventHandler const& handler) const;public event UnhandledExceptionEventHandler UnhandledException;function onUnhandledException(eventArgs) { /* Your code */ }
application.addEventListener("unhandledexception", onUnhandledException);
application.removeEventListener("unhandledexception", onUnhandledException);
- or -
application.onunhandledexception = onUnhandledException;Public Custom Event UnhandledException As UnhandledExceptionEventHandler イベントの種類
注釈
イベントはUnhandledException、XAML フレームワークまたは一般にアプリ コードによって処理されていないWindows ランタイムによって検出された例外についてアプリに通知するために使用されます。
たとえば、Windows ランタイムがイベント ハンドラーなどのアプリ コードを呼び出し、アプリ コードが例外をスローしてキャッチしない場合、例外はWindows ランタイムに反映されます。 その後、Windows ランタイムによってイベントがUnhandledException発生し、この例外がアプリに通知されます。
での例外の UnhandledException 処理は、デバッグと実行時例外処理と可能な復旧の両方に使用できる多くの手法の 1 つに過ぎません。 デバッグとエラー処理に使用できる手法の完全なセットの詳細については、「 例外処理 (C# プログラミング ガイド)」を参照してください。
このイベントは、アプリ コードが例外をキャッチできる可能性がなくなった場合にのみ発生します。 たとえば、アプリ イベント ハンドラーがコールバックを呼び出すWindows ランタイム API を呼び出すとします。 内部アプリ コードが例外をスローし、それをキャッチしない場合、例外はWindows ランタイムを介してアプリ コードの外部レイヤーに反映され、それをキャッチする機会が与えられます。 イベントは UnhandledException 、アプリ コードが通常の伝達によって例外をキャッチする機会がなくなった場合にのみ発生します。
また、例外がスローされ、アプリ コードによってキャッチされる機会がない可能性もあります。 たとえば、XAML フレームワークがレイアウトを実行していて、例外がスローされた場合、この例外はアプリ コードを通じて伝達されません。 この場合、イベントが UnhandledException 発生し、例外についてアプリ コードに通知されるのはこれが初めてになります。
通常、イベントがUnhandledException発生した後、例外が処理されていないため、Windows ランタイムはアプリを終了します。 アプリ コードでは、イベント ハンドラーがイベント引数の UnhandledExceptionHandled プロパティを に true設定した場合、ほとんどの場合、アプリは終了しません。 ただし、いくつかの理由から、定期的に行うことはお勧めしません。
- 通常、
UnhandledExceptionイベント ハンドラーには、例外が安全な後に継続するかどうかを知るのに十分な情報がありません。 アプリケーション コードまたはWindows ランタイムの一部が一貫性のない状態になっている可能性があります。これにより、アプリでコードの実行が続行されると、後続のエラーが発生する可能性があります。 - Windows ランタイムでは、特定の操作中に発生した例外は回復不可能と見なされます。これは、Windows ランタイム自体がこれらの例外の後に不整合な状態になるためです。 このような例外の場合、イベント ハンドラーが
UnhandledExceptionHandled を にtrue設定した場合でも、アプリは終了します。 - ナビゲーション中に発生するエラーにより、コンテンツとして何も読み込まれ、アプリがまだ実行されていることをユーザーに示すものがない状態が発生する可能性があります。
- これらの点の詳細については、「 例外処理 (C# プログラミング ガイド)」を参照してください。
注目すべき制限は、イベント引数に UnhandledException 、アプリ コードから伝達される元の例外ほど詳細が含まれていない点です。 可能な限り、アプリで特定の例外の特定の処理が必要な場合は、より詳細な情報が使用可能になるため、例外が伝達されるときに常にキャッチすることをお勧めします。 イベント引数は UnhandledException 、 Exception プロパティを使用して例外オブジェクトを公開します。 ただし、この例外オブジェクトの型、メッセージ、スタック トレースは、発生した元の例外と一致する保証はありません。 イベント引数は Message プロパティを公開します。 ほとんどの場合、これには最初に発生した例外のメッセージが含まれます。
XAML で ハンドラー UnhandledException をワイヤ化することはできません (App.xaml の Application 要素)。 のハンドラーは UnhandledException 、コンストラクターまたはアクティブ化ロジックのコード内の Application オブジェクトにアタッチする必要があります。