Winforms-MVPとWPF-MVVMで例外のエンドユーザーに知らせる

Question

Winforms-MVPの半年の間、私は次の例外処理戦略を設計しました。私は、いくつかのExecuteメソッドが入力パラメータとしてデリゲートを取る基本的なPresenterクラスを持っています（シグネチャは異なります）。ビューとプレゼンタとの間のインタラクションは、IViewで定義されたイベント（入力）と、IViewで定義され、Viewで実装されたパブリックプロパティ（出力）または呼び出しメソッドを設定することによって行われます。プレゼンターの各イベントハンドラーは、具体的な実現を提供するExecuteメソッドの1つを呼び出します。

実行メソッドでは、（主に広く使用されている外部コンポーネントのいくつかの問題のために）発生する可能性がある非常に明確な例外のためのいくつかのキャッチブロックがあります。これらの例外のそれぞれは、現在の操作の実行を停止し、ログに記録され、Viewのメソッドを呼び出すことによって意味のある説明がユーザーに表示されます。

私はWPF-MVVMを学び始めました。最初の一見からMVPとよく似ているようです。私はそこでの例外処理戦略（主にユーザーに問題点を知らせる）に関するいくつかの便利なアドバイスを探していましたが、この質問は一般的には検索するのが難しいです。私は、app.xaml.csで未処理の例外を "処理"する20以上の例を見つけました。これはすべてとても良いですが、心から教えてください。アプリをクラッシュさせる可能性のある厳密な例外を知っていれば、ちょっと早く（たとえあなたがアプリを閉じることを余儀なくされても）？私はすべての可能な例外をキャッチするファンではありません。ネットワークの問題、一時的なデータベースの利用不能などによって引き起こされる非常に多くの例外は、通常のユーザーに要求を繰り返す恐れのある恐ろしいエラーアイコンなしでアプリケーションを終了することなく処理する必要があります。

実験として、前に説明したのとほぼ同じことを試しました。私は、ViewModelでイベントを作成しました。しかし、率直に言って、この方法は私に忍び寄る。

（これは非常に長い話でした）質問： MVVMを使用しているときに通知することに関する例外をどのように処理しますか？いいえ、私は今のところデータ検証に興味がありません。 MVPに関する批判やアドバイスも歓迎します。

Answer 1

私たちのWpfアプリケーションでは、さまざまな種類のエラー条件に対して、さまざまな戦略があります。

コードが処理してユーザーに通知せずに処理できる予期しないエラーについては、通常のTry Catchブロックを実行します。

ユーザーの視点ではエラーが発生すると予想されるエラーについては、ViewのItemsControlにバインドされているViewModelsにNotificationsコレクションが公開されています。これは、通知バーと同様にテンプレート化されています。 Firefox/IE/Chrome各通知には、表示時間プロパティ（通知コレクションはディスパッチャタイマーを使用した自己プルーニング）とビュー内の閉じるボタンがあり、特定の期間表示されるか、ユーザーが明示的に閉じることができます。このモデルの素晴らしい点は、Completionメッセージ、警告、例外、および例外としては現れないかもしれないが、ユーザーの観点からは依然としてエラー状態であるいくつかの条件にも使用できることです。通知は、ユーザーのワークフローを中断しないため、メッセージボックスの代わりになることがよくあります。

Red Gate SmartAssemblyを使用して詳細を把握することはできませんが、ユーザーが解析のサポートに送ることができると思われるエラーについては、私たちの見解では、予期しなかった例外が非常に危険な戦略である場合に、あなたのアプリをキャッチし続けることです。予期しない例外からのスタックは解消されず、エラーの後でアプリは一貫性のない状態になります。奇妙なUIから壊れたデータまで）、予測することが不可能な副作用が存在する可能性があります。アプリがクラッシュするのはユーザーエクスペリエンスが優れているわけではありませんが、アプリで無視されたエラーによって予期しない状態が発生したため、データを破損させることは非常に悪い経験です。私たちの戦略は、クラッシュについての詳細を把握して、ユーザーが問題に真剣に取り組んでいることを知っているので、悪質な問題を抱えているだけでなく、将来のアップデートで修正/捕捉します。

Answer 2

私は同意します。あなたのapp.xaml.csに例外の処理を残しておくのは、基本的には遅すぎるので、それは良いことではありません！

潜在的な例外（ファイル処理、ネットワークIO）が比較的高い操作では、例外を積極的にキャッチするようにしてください。 I 2つの方法のいずれかでのビューにこれを公開します。たとえば、いくつかの長時間実行の問題、ネットワークの問題を示すエラーについて

1. 、私は一過性の問題については「ErrorState」poperty
2. を公開し、ファイルが見つかりませんたとえば、イベントを公開します。