在Winforms-MVP的半年时间里，我设计了如下的异常处理策略。我有一个基本的抽象 Presenter 类，其中有几个 Execute 方法将委托(delegate)作为输入参数(签名各不相同)。 View 和 Presenter 之间的交互是通过 IView 中定义的事件(输入)以及设置公共(public)属性(输出)或调用 IView 中定义并由 View 实现的方法来完成的。 Presenter 中的每个事件处理程序都调用其中一个 Execute 方法，为其提供具体实现。
在execute方法中我有几个catch block ，用于非常明确的可能发生的异常(主要是因为广泛使用的外部组件中的一些问题)。这些异常中的每一个都会停止当前操作的执行，被记录下来并通过调用 View 的方法向用户显示有意义的解释。
不久前(事实上非常不久前)我开始学习 WPF-MVVM，乍一看似乎与 MVP 有很多共同点。我一直在寻找有关异常处理策略的一些方便的建议(主要是通知用户有关问题)，但一般来说很难搜索到这些问题——我的意思是，说了很多，但主要是原则上的。我在 app.xaml.cs 中找到了 20 多个“处理”未处理异常的示例，这一切都非常好，但请真诚地告诉我 - 如果您知道可能使您的应用程序崩溃的确切异常，您会不会处理它们？早一点(即使您将被迫关闭您的应用程序)？我不喜欢捕捉所有可能的异常。很多由网络问题、临时数据库不可用等引起的异常应该在不关闭应用程序的情况下处理，没有可怕的错误图标，让普通用户有机会重复他的请求。
因此，作为一项实验，我尝试了与我之前描述的几乎相同的事情 - 我在 ViewModel 中创建了事件以进行异常转换，并为它们订阅了 View。但是，坦率地说，这种方式让我毛骨悚然。
(这是一个很长的演讲，我知道)问题:在使用 MVVM 时，您如何处理与通知用户相关的异常？不，我暂时对数据验证不感兴趣。也欢迎任何关于 MVP 的批评和/或建议。
最佳答案
我们针对 Wpf 应用程序中不同类型的错误条件采用了几种不同的策略。
对于代码可以在不通知用户的情况下处理和继续的预期错误，我们执行正常的 Try Catch block 。
对于预期的错误，但从用户的角度来看会导致失败，我们在 ViewModels 上公开一个通知集合，绑定(bind)到我们的 View 上的 ItemsControl，它在类似的模板中Firefox/IE/Chrome 中通知栏的方式。每个通知都有一个显示持续时间属性(通知集合使用调度程序计时器进行 self 修剪)和 View 中的关闭按钮，以便它们可以在特定时间段内显示或可以由用户显式关闭。这个模型的好处是它可以用于完成消息、警告和异常——以及一些可能不会表现为异常但从用户角度来看仍然是错误条件的情况。通知通常是消息框的一个很好的替代品，因为它们不会中断用户的工作流程。
对于我们未预料到的错误，我们使用 Red Gate SmartAssembly捕获完整的详细信息，以便用户可以将它们发送给我们的支持人员进行分析。我们的观点是，在您没有预料到的异常发生后捕获并继续您的应用程序是一种非常冒险的策略 - 来自意外异常的堆栈不会展开并且您的应用程序将在错误发生后处于不一致状态(这可能导致从奇怪的 UI 到损坏的数据)，并且可能会产生无法预测的副作用。应用程序崩溃并不是很好的用户体验，但由于应用程序忽略的错误导致意外状态而导致数据损坏，这是一种非常糟糕的体验。我们的策略是捕获有关崩溃的尽可能多的详细信息，以便用户知道我们对解决问题是认真的，我们将在未来的更新中修复/捕获它 - 而不是继续进行并解决可能更严重的问题。
关于c# - 通知最终用户 Winforms-MVP 和 WPF-MVVM 中的异常，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6473021/