向Winforms-MVP和WPF-MVVM中的異常通知最終用戶

Question

在Winforms-MVP的半年中，我設計了以下異常處理策略。我有一個基本的抽象Presenter類，其中包含幾個Execute方法，將委託作爲輸入參數（簽名不同）。 View和Presenter之間的交互是通過IView中定義的事件（輸入）完成的，並通過設置公共屬性（輸出）或調用在IView中定義並由View實現的方法來完成。演示者中的每個事件處理程序調用Execute方法之一，爲其提供具體實現。

在執行方法中，我有幾個catch塊可能會出現非常明確的異常（主要是因爲廣泛使用的外部組件中存在一些問題）。這些異常中的每一個都會停止當前操作的執行，並通過調用View的方法來記錄並向用戶顯示有意義的解釋。不久前（事實上很久以前）我開始學習WPF-MVVM，乍一看似乎與MVP有許多共同之處。我在尋找關於異常處理策略的一些方便的建議（主要是向用戶通知有關問題），但這個問題一般難以搜索 - 我的意思是，很多人說，但主要是原則上。我發現了20多個在app.xaml.cs中「處理」未處理的異常的例子，這一切都非常好，但真誠地告訴我 - 如果你知道確切的異常可能會導致你的應用程序崩潰，你會不會處理它們稍早（即使您將被迫關閉您的應用程序）？我不是追求所有可能的例外的粉絲。應該處理很多由網絡問題，臨時數據庫不可用等造成的異常，而不關閉應用程序，而沒有可怕的錯誤圖標讓普通用戶有機會重複他的請求。

因此，作爲一個實驗，我嘗試了幾乎與前面描述的相同的事情 - 我在ViewModel中創建了異常轉換和訂閱View的事件。但坦率地說，這種方式讓我毛骨悚然。

（這是一個很長的演講，我知道）問題：如何處理使用MVVM時通知用戶的異常？不，我現在對數據驗證不感興趣。任何關於MVP的批評和/或建議也是受歡迎的。

Answer 1

對於我們的Wpf應用程序中的各種錯誤條件，我們有幾種不同的策略。

對於代碼可以處理和繼續而不通知用戶的預期錯誤，我們執行正常的Try Catch塊。

對於預期的錯誤，但從用戶的角度來看導致失敗，我們在我們的ViewModels上公開一個Notifications集合，綁定到我們的View上的ItemsControl，它以與通知欄類似的方式模板化火狐/ IE /鉻。每個通知具有節目​​持續時間屬性（在通知集合是使用調度計時器自修剪），並在視圖中的關閉按鈕，使得它們可以出現在特定的時間段，或者可以由用戶明確地關閉。關於這種模式的好處是，它可以用於完成消息，警告和例外 - 也有一些情況，可能不表現爲異常但仍從用戶的角度看錯誤條件。通知通常可以替代消息框，因爲它們不會中斷用戶工作流程。

爲此，我們並不預期我們用Red Gate SmartAssembly捕捉到的全部細節，因此用戶可以將它們發送到我們的分析支持錯誤。我們的觀點是，捕捉和你沒有預料異常之後，繼續你的應用程序是一個非常冒險的策略 - 從一個意外的異常堆棧沒有解開，你的應用程序將處於不一致的狀態錯誤後留下的（這可能導致從怪異的用戶界面到腐敗的數據）以及可能存在無法預測的副作用。應用程序崩潰並不是一個好用戶體驗，但是由於應用程序忽略的錯誤導致意外狀態，導致數據損壞，這是一種嚴重不良的體驗。我們的策略是捕捉儘可能多的關於碰撞的細節，因此用戶知道我們對解決問題非常認真，並且我們會在未來的更新中修復/抓住它 - 而不是繼續前進並尋找潛在的更糟糕的問題。

Answer 2

我同意，在你的app.xaml.cs中處理異常並不好，因爲它基本上太晚了！

對於潛在異常相對較高的操作（文件處理，網絡IO），請確保您主動捕獲異常。我在兩種方式之一揭露這觀點：

1. 對於表明一些長期運行的問題，錯誤，網絡問題，例如，我露出一個「ErrorState」 poperty
2. 對於瞬態問題，找不到文件例如，揭露一個事件。