次の方法で共有


Application.UnhandledException イベント

定義

ネイティブ レベルの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 、アプリ コードから伝達される元の例外ほど詳細が含まれていない点です。 可能な限り、アプリで特定の例外の特定の処理が必要な場合は、より詳細な情報が使用可能になるため、例外が伝達されるときに常にキャッチすることをお勧めします。 イベント引数は UnhandledExceptionException プロパティを使用して例外オブジェクトを公開します。 ただし、この例外オブジェクトの型、メッセージ、スタック トレースは、発生した元の例外と一致する保証はありません。 イベント引数は Message プロパティを公開します。 ほとんどの場合、これには最初に発生した例外のメッセージが含まれます。

XAML で ハンドラー UnhandledException をワイヤ化することはできません (App.xaml の Application 要素)。 のハンドラーは UnhandledException 、コンストラクターまたはアクティブ化ロジックのコード内の Application オブジェクトにアタッチする必要があります。

適用対象

こちらもご覧ください