2016-06-30 8 views
0

App.UnhandledException e.Exceptionに初めてアクセスするときに、期待どおりにメッセージとスタックトレースが返されます。もう一度アクセスすると、 "Exception type 'System.Exception'がスローされました。"というメッセージが返されます。UnhandledExceptionEventArgs.Exceptionが最初のアクセスでのみ有用な情報を返すのはなぜですか?

これはバグですか、何が起こっていますか?

例:( "テストアプリのクラッシュ" $)新しいMyCustomExceptionを投げる

Private Sub App_UnhandledException(sender As Object, e As UnhandledExceptionEventArgs) Handles Me.UnhandledException 
    Dim ex1 = e.Exception 
    Debug.WriteLine($"ex1={ex1}") 
    Dim ex2 = e.Exception 
    Debug.WriteLine($"ex2={ex2}") 
End Sub 

での結果:

ex1=ErrorHandlingDemo.MyCustomException: Testing app crash. 
    at ErrorHandlingDemo.MainPage.btnForceUnhandledEx_Click(Object sender, RoutedEventArgs e) 
    at Windows.ApplicationModel.Core.UnhandledError.Propagate() 
    at ... 

ex2=System.Exception: Exception of type 'System.Exception' was thrown. 

私はe.Messageは、元のメッセージ(および中を保持し承知していますデバッグはスタックトレースの一部を構築します)。 最初のアクセスで貴重な情報を返すe.Exceptionの動作はまだ変わっているようです。

回避策として、まずローカル変数に割り当ててからこれを使用します。一つでも気をつけなければならないこの回避策と

Dim ex = e.Exception 
Trace(ex) 
If Typeof(ex) is MyCustomException 
... 

:(e.Exceptionにアクセスするためにデバッガに引き起こす)割り当ての前にブレークポイントを設定することは、元の値を破壊します。

でも簡単にブレークポイントを設定することがUnhandledExceptionEventArgs.Exceptionの元の値を破壊するので、これは特に非常に紛らわしい行動であるsample code.

答えて

1

を参照してください。 MSはこの動作を変更するか、少なくともそれを文書化する必要があります。ローカル変数に、次の例外の詳細をex.Exceptionを割り当てるの回避策で

が用意されています。私のブログの記事Global Error Handling for UWP-Appsが役に立つかもしれませんUWP-アプリで予期しない例外処理について、さらにアイデアを Unhandled exception infos debug vs release mode

関連する問題