How do I continue running after an unhandled exception?

Question

I have the following code in my application that is running after an unhandled exception:

AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
        {
            var exception = e.ExceptionObject as Exception;
            if (exception != null) MessageBox.Show(exception.Message + " - " + exception.StackTrace);
        }

but even if i catch unhandled exception my windows mobile application close. How to prevent closing application when i catch unhandled exception. I never want to close my app. I want to open Login form in this scenario or anything else not close app.

So what i want is to prevent closing application from unhandled exception like network is down,...

I can not use try catch in every code ....

Any idea how to prevent closing app when network is down or any other unhandled exceptions?

Solution 1

You don't. When you get an AppDomain unhandled exception, your app is no longer in a stable state. Where exactly would you resume to? When you've gotten to that point, your only option, with good reason, is to exit. You could reasonably schedule yourself to run again to make sure the app comes back, but a far better idea is to actually handle the exception at its source and prevent it from being an UnhandledException.

Solution 2

In your app.config add the following element

<runtime>
  <!-- the following setting prevents the host from closing when an unhandled exception is thrown -->
  <legacyUnhandledExceptionPolicy enabled="1" />
</runtime>

Solution 3

You can, and you should use try...catch and handle the exceptions in every situation where an exception might occur. (In languages like Java you can't even compile your code until you catch every exception that the called function might throw or declare explicitly that this particular function won't catch it, so the one that calls it should do it.)

If you want to minimize the cases where you use try...catch some bad situations can be prevented with testing if the necessary conditions are met so you won't even call a function that is known for throwing a particular exception. Like calling

if (myByteArray != null)
{
    myIPAddress = new IPAddress(myByteArray);
}

because this way the IPAddress constructor won't throw an ArgumentNullException.

However in most of the cases this can't be done, especially with networking, because you can't predict if the cable will be cut, the signal will be lost, the database server will crush, etc. in the middle of the transaction. So you should try...catch every time you connect to the network or send data to or receive data from a connection.

Solution 4

AppDomain.CurrentDomain.UnhandledException fires on any unhandled exception on any thread, but since CLR 2.0, the CLR forces application shutdown after your event handler completes. However, you can prevent shutdown by adding the following to your application configuration file:

<configuration>
  <runtime>
    <legacyUnhandledExceptionPolicy enabled="1" />
  </runtime>
</configuration>

View more solutions

Comments

[Renatas M.]

have you tried to surround all code in main method with try catch?

[Renatas M.]

Or maybe try to change capability flag. Read more here

[senzacionale]

ty catch for main method not helping. Still the same.

[Renatas M.]

And how about changing capability flag?

[senzacionale]

I search in google but i do not know what capability flag means

[Renatas M.]

Sorry I misspelled :) Its compatibility flag. In the articles bottom see section "Application Compatibility Flag"

[gingerbreadboy]

FYI This solution is detailed here (Method 2) support.microsoft.com/kb/911816 Microsoft says We do not recommend that you change the default behavior. If you ignore exceptions, the application may leak resources and abandon locks.

[Thomas Weller]

This answer was already given 2 years ago by Robert Slade Lewis

[Bryce Wagner]

Application.ThreadException is specific to WinForms, and it basically means that Application.Run() will handle the exception by passing it on to you, instead of letting it propagate out of Run() (and therefore stopping the message pump). It doesn't handle anything on threads where the message pump isn't running.

[faridSam]

Not really. If you insist on handling all exceptions at the point where they occur then you will end up sometimes resuming execution when the application is no longer in a stable state. Instead, handle all of of the specific exceptions that you can meaningfully recover from at the point where you can best recover, and let all other exceptions bubble up. AppDomain.CurrentDomain.UnhandledException is a last resort that allows you to do something like log the exception or display a crash dialog, but quite rightly you cannot recover at this point.

[ytg]

I've worked on an application before that ran on an older Windows CE device in kiosk mode. It was a business requirement that the user should never ever ever be able to leave the application. Yes, handling some exceptions would leave the application in an unstable state. Yes, the normal way to go is with UnHandledException. But the question was about not leaving the application, and sometimes that is more important than remaining in a stable state.

[faridSam]

In that situation the last resort exception handler should start a new instance of the application before letting the current instance die. Trying to limp on after any exception that you cannot explicitly handle is madness because you have no idea of the state of your application's internal data. If you think buffer overruns are bad...

[Thomas Weller]

It seems this does not work in app.config. The article linked by @gingerbreadboy says the code needs to be in %WINDIR%\Microsoft.NET\Framework\v2.0.50727\aspnet.config