Application.UnhandledException イベント

  • リファレンス

定義

名前空間:
Windows.UI.Xaml
編集

ネイティブ レベルの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

イベントの種類

UnhandledExceptionEventHandler

注釈

UnhandledException イベントは、XAML フレームワークまたは一般にアプリ コードによって処理されていないWindows ランタイムによって検出された例外についてアプリに通知するために使用されます。

たとえば、Windows ランタイムがイベント ハンドラーなどのアプリ コードを呼び出し、アプリ コードが例外をスローし、それをキャッチしない場合、例外はWindows ランタイムに反映されます。 その後、Windows ランタイムは UnhandledException イベントを発生し、この例外をアプリに通知します。

UnhandledException での例外の処理は、デバッグと実行時例外処理と可能な復旧の両方に使用できる多くの手法の 1 つに過ぎません。 デバッグとエラー処理に使用できる手法の完全なセットの詳細については、「 C# または Visual Basic での の例外処理」を参照してください。

このイベントは、アプリ コードが例外をキャッチできる可能性がなくなった場合にのみ発生します。 たとえば、アプリ イベント ハンドラーがコールバックを呼び出すWindows ランタイム API を呼び出すとします。 内部アプリ コードが例外をスローし、それをキャッチしない場合、例外はWindows ランタイムを介してアプリ コードの外部レイヤーに反映され、それをキャッチする機会が与えられます。 UnhandledException イベントは、アプリ コードが通常の伝達によって例外をキャッチする機会がなくなった場合にのみ発生します。

また、例外がスローされ、アプリ コードによってキャッチされる機会がない可能性もあります。 たとえば、XAML フレームワークがレイアウトを実行していて、例外がスローされた場合、この例外はアプリ コードを通じて伝達されません。 この場合、UnhandledException イベントが発生し、例外についてアプリ コードに通知されるのはこれが初めてとなります。

通常、UnhandledException イベントが発生した後、例外が処理されていないため、Windows ランタイムはアプリを終了します。 アプリ コードは、これを制御します。UnhandledException イベント ハンドラーがイベント引数の Handled プロパティを true に設定した場合、ほとんどの場合、アプリは終了しません。 ただし、いくつかの理由から、定期的に行うことはお勧めしません。

  • 通常、UnhandledException イベント ハンドラーには、例外が安全な後に継続するかどうかを知るのに十分な情報がありません。 アプリケーション コードまたはWindows ランタイムの一部が一貫性のない状態になっている可能性があります。これにより、アプリでコードの実行が続行されると、後続のエラーが発生する可能性があります。
  • Windows ランタイムでは、特定の操作中に発生した例外は回復不可能と見なされます。これは、Windows ランタイム自体がこれらの例外の後に不整合な状態になるためです。 このような例外の場合、UnhandledException イベント ハンドラーが Handled を true に設定した場合でも、アプリは終了します。
  • ナビゲーション中に発生するエラーにより、コンテンツとして何も読み込まれ、アプリがまだ実行されていることをユーザーに示すものがない状態が発生する可能性があります。
  • これらのポイントの詳細については、「 C# または Visual Basic での の例外処理」を参照してください。

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

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

Windows 8.1 アプリの場合、非同期メソッド呼び出しからの例外は UnhandledException イベントとして伝達される可能性があります。 これには、独自の非同期メソッド実装 (アクティブ化ハンドラーなど) が含まれます。

適用対象

こちらもご覧ください