Mdthbs

What is best practice when a unhandled exceptions occurs in a desktop application?

I was thinking about to show a message to the user, so that he can contact support. I would recommend to the user to restart the application, but not force it. Similar to what is discussed here: ux.stackexchange.com - What's the best way to handle unexpected application errors?

The project is a .NET WPF application, so the described proposal could look like this (Note that this is a simplified example. Probably it would make sense to hide the exception details until the user click on "Show Details" and provide some functionality to easily report the error):

public partial class App : Application

{

    public App()

    {

        DispatcherUnhandledException += OnDispatcherUnhandledException;

    }



    private void OnDispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)

    {

        LogError(e.Exception);

        MessageBoxResult result = MessageBox.Show(

             $"Please help us fix it and contact support@example.com. Exception details: {e.Exception}" +

                        "We recommend to restart the application. " +

                        "Do you want to stop the application now? (Warning: Unsaved data gets lost).", 

            "Unexpected error occured.", MessageBoxButton.YesNo);



        // Setting 'Handled' to 'true' will prevent the application from terminating.

        e.Handled = result == MessageBoxResult.No;

    }



    private void LogError(Exception ex)

    {

        // Log to a log file...

    }

}

In the implementation (Commands of ViewModels or event handler of external events) I would then only catch the specific exogenous exception and let all other exceptions (boneheaded and unknown exceptions) bubble up to the "Last resort handler" described above. For a definition of boneheaded and exogenous exceptions have a look at: Eric Lippert - Vexing exceptions

Does it make sense to let the user decide if the application should be terminated?
When the application is terminated, then you for sure have no inconsistent state... On the other hand the user may loose unsaved data or is not able to stop any started external process anymore until the application is restarted.

Or is the decision if you should terminate the application on unhandled exceptions depending of the type of application you are writting? Is it just a trade off between "robustness" vs. "correctness" like described in Code Complete, Second Edition

To give you some context what kind of application we are talking about:
The application is mainly used to control chemical lab instruments and show the measured results to the user. To do so the WPF applications communicates with some services (local and remote services). The WPF application does not communicate directly with the instruments.

It depends to some extent on the application you're developing but in general, I'd say that if your application encounters an unhandled exception, you need to terminate it.

Why?

Because you can no longer have any confidence in the state of the application.

Definitely, provide a helpful message to the user, but you should ultimately terminate the application.

Edit having looked at the context, I would definitely want the application to terminate. You do not want software running in a lab to produce corrupt output and since you didn't think to handle the exception, you have no idea why it was thrown and what is happening.

You have to expect your program to terminate for more reasons than just an unhandled exception anyway, like a power failure, or a different background process which crashes the whole system. Therefore I would recommend to terminate and restart the application, but with some measures to mitigate the consequences of such a restart and minimize the possible data loss.

Start with analysing the following points:

• how much data can actually get lost in case of a program termination?




• how severe is such a loss really for the user? Can the lost data reconstructed in less than 5 minutes, or are we talking about losing a days work?




• how much effort it is for you to implement some "intermediate backup" strategy (which saves not to the data pool where, as you wrote, the user would have to enter a change reason, but to something like a temporary file, which may be reloaded after a program crash automatically)?




• in case data was wrong or corrupted, can the user see this easily (maybe after a restart of the program)? If yes, you may offer an option to let the user save the data, then force a restart, reload it and let the user check if the data looks fine.

If that this "intermediate backup" strategy is a sensible option depends ultimately on the application and its architecture, and on the nature and structure of the data involved. But if the user will loose less than 10 minutes of work, and such a crash happens once a week or even more seldom, I would probably not invest too much thought into this.

Considering that this is meant for a chemical lab and that your application does not control the instruments directly but rather through other services:

Force termination after showing the message. After an unhandled exception your application is in an unknown state. It could send erroneous commands. It can even invoke nasal demons. An erroneous command could potentially waste expensive reagents or bring danger to equipment or people.

But you can do something else: gracefully recover after restarting. I assume that your application doesn't bring down those background services with itself when it crashes. In that case you can easily recover the state from them. Or, if you have more state, consider saving it. In a storage which has provisions for data atomicity and integrity (SQLite maybe?).