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