Informing the end user about exceptions in Winforms-MVP and WPF-MVVM

Question

Over the course of six months of Winforms-MVP, I developed the following exception handling strategy. I have a base abstract class Presenter with several Execute methods that take a delegate as an input parameter (signatures change). The interaction between the presentation and the presenter is carried out using events (input) defined in IView, and by setting public properties (output) or calling methods defined in IView, as well as implemented by View. Each event handler in the presenter calls one of the Execute methods, providing it with a specific implementation.

In the execution method, I have several catch blocks for very specific exceptions that may occur (mainly due to some problems in external components that are widely used). Each of these exceptions stops the execution of the current operation, registers and displays to the user with a meaningful explanation, calling the viewing methods.

Not so long ago (actually VERY not so long ago) I began to study WPF-MVVM, which at first glance seems to have a lot in common with MVP. I was looking for some useful tips regarding the exception handling strategy there (mostly informing the user about the problems), but these questions are hard to find at all - I mean, a lot has been said, but mainly in principle. I found more than 20 examples of "handling" unhandled exceptions in app.xaml.cs, all of which are very nice, but tell me sincerely - if you know the exact exceptions that could lead to an application crash, would you handle them a little earlier (even if you will be forced to close the application)? I am not a fan of all possible exceptions. Quite a few exceptions caused by network problems, temporary unavailability of the database, etc., should be handled without closing the application without errors and errors, which gives ordinary users the opportunity to repeat its request.

So, as an experiment, I tried almost the same thing that I described earlier - I created events in the ViewModel to jump to exceptions and subscribed to them. But honestly, this path gives me crawls.

(It was a very long speech, I know) Question: how do you handle exceptions in terms of informing the user when using MVVM? No, at the moment I'm not interested in data verification. Any criticism and / or advice on MVP is also welcome.

Answer 1

Our Wpf applications have several different strategies for different types of errors.

For the expected errors that the code can process and continue without notifying the user, we make the usual Try Catch blocks.

For the expected errors that lead to a crash from the point of view of users, we present a collection of notifications on our ViewModels models bound to the ItemsControl element on our View , which is template-modeled like notification bars in Firefox / IE / Chrome. Each notification has the show duration property (a collection of self-learning notifications using the dispatcher timer) and a close button in the view so that they can be displayed for a certain period of time or can be explicitly closed by the user. The nice thing about this model is that it can be used for Completion messages, warnings and exceptions, as well as some conditions that may not appear as an exception, but which are still errors from the point of view of users. Notifications are often a good replacement for the message box, as they do not interrupt the users workflow.

For errors that we do not expect, we use Red Gate SmartAssembly to get complete information so that users can send them to our analysis support. Our opinion is that catching and continuing the application after exceptions that you did not expect is very a risky strategy - the stack from an unexpected exception is not unwound, and after an error your application will remain in an inconsistent state (which can lead to something from a strange user interface to corrupt data), and may be side effects that cannot be predicted. This is not a great user interface that can lead to an application crash, but it is much worse if it corrupts data due to an unexpected state caused by an error that was ignored by the application. Our strategy is to capture as much detail as possible about the failure, so the user knows that we are serious about solving the problem, and we will get it fixed / caught in a future update, and not just continue and go to potentially more serious problems.

Answer 2

I agree leaving the exception handling in your app.xaml.cs not very good, because it's basically too late!

For operations in which the potential exception is relatively large (file processing, network I / O), make sure that you actively catch exceptions. I present this for presentation in one of two ways:

• For errors that indicate some problems with a long time, for example, problems with the network, I show "ErrorState" poperty
• For temporary problems, a file not found, for example, exposes an event.