Informing end user of exceptions in Winforms-MVP and WPF-MVVM

Question

During half a year of Winforms-MVP I designed the following exception handling strategy. I have a base abstract Presenter class with several Execute methods taking a delegate as input parameter (signatures vary). Interaction between the View and Presenter is done via events (input) defined in the IView and by setting public properties (output) or calling methods defined in the IView as well and implemented by the View. Each event handler in the presenter calls one of the Execute methods providing it with concrete realization.

In the execute method I have several catch blocks for very definite exceptions that may occur (mainly because of some problems in the external components that are widely used). Each of these exceptions stops the execution of the current operation, is being logged and shown to the user with meaningful explanation by calling View's methods.

Not long ago (in fact VERY not long ago) I started learning WPF-MVVM which from the first glance seems to have much in common with MVP. I was looking for some handy advice concerning exception handling strategy there (mainly informing the user about problems), but this questions are difficult to search for in general - I mean, much is said, but mainly in principle. I've found more than 20 examples of "handling" unhandled exceptions in the app.xaml.cs, it's all very nice, but tell me sincerely - if you know exact exceptions that may crash you app, won't you handle them a little bit earlier (even if you will be forced to close your app)? I'm no way a fan of catching all the possible exceptions. Quite a lot of exceptions that are caused by the network problems, temporary database unavailability and so on should be handled without closing the application without scary error icons giving an ordinary user a chance to repeat his request.

So as an experiment I tried almost the same thing as I described earlier - I've created events in ViewModel for exceptions transition and subscribed View to them. But, frankly speaking, this way gives me creeps.

(It was a very long speech, I know) The question: how do you handle exceptions in what is concerning informing user when using MVVM? No, I'm not interested in data validation just for now. Any criticism and/or advice about MVP is also welcome.

Answer 1

We have a couple of different strategies for different kinds of error conditions in our Wpf apps.

For anticipated errors that the code can handle and proceed without notifying the user, we do the normal Try Catch blocks.

For errors that are anticipated but that result in a failure from the users point of view, we expose a Notifications collection on our ViewModels, bound to an ItemsControl on our View which is templated in a similar way to the notification bars in Firefox/IE/Chrome. Each notification has a show duration property (the Notifications collection is self pruning using a dispatcher timer) and a close button in the view, so that they can appear for a specific period of time or can be closed explicitly by the user. The nice thing about this model is that it can be used for Completion messages, warnings and exceptions - and also some conditions that might not manifest as an exception but that are still error conditions from the users point of view. Notifications are often a good replacement for the message box as they don't interrupt the users workflow.

For errors that we don't anticipate we use Red Gate SmartAssembly to capture full details so users can send them to our support for analysis. Our view is that catching and continuing your app after exceptions that you haven't anticipated is a very risky strategy - the stack from an unexpected exception is not unwound and your app will be left in an inconsistent state after the error (which could result in anything from a weird UI to corrupt data) and there could be side effects that are impossible to predict. It's not a great user experience to have an app crash, but it's a significantly worse experience to have it corrupt data because of an unanticipated state caused by an error that was ignored by the app. Our strategy is to capture as much detail about the crash so the user knows we are serious about addressing the problem and we will get it fixed / caught in a future update - rather than just carrying on and heading for potentially worse problems.

Answer 2

I agree, leaving the handling of exceptions in your app.xaml.cs is not good, because it is basically too late!

For operations where a potential exception is relatively high (file handling, network IO), ensure that you actively catch exceptions. I expose this to the view in one of two ways:

1. For errors that indicate some long-running issue, network problems for example, I expose an 'ErrorState' poperty
2. For transient issues, file not found for example, expose an event.