2

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?

ctacke
  • 66,480
  • 18
  • 94
  • 155
senzacionale
  • 20,448
  • 67
  • 204
  • 316

5 Answers5

6

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.

ctacke
  • 66,480
  • 18
  • 94
  • 155
4

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>
  • **FYI** This solution is detailed here (Method 2) http://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.` – gingerbreadboy Jun 11 '14 at 13:17
  • 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 – Thomas Weller Jun 09 '19 at 20:38
2

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.

ytg
  • 1,755
  • 2
  • 23
  • 41
  • 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. – Ian Goldby Jul 04 '18 at 10:35
  • 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. – ytg Jul 04 '18 at 12:07
  • 1
    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... – Ian Goldby Jul 04 '18 at 12:17
1

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>
Anil8753
  • 2,663
  • 4
  • 29
  • 40
0

I think you need to use Application.ThreadException When you subscribe to Application.ThreadException, unhandled exceptions wont hit the UnhandledException and the app will keep running.

Renatas M.
  • 11,694
  • 1
  • 43
  • 62
  • have you tried to surround all code in main method with try catch? – Renatas M. Oct 18 '11 at 13:27
  • Or maybe try to change capability flag. Read more [here](http://msdn.microsoft.com/en-us/library/ms228965.aspx) – Renatas M. Oct 18 '11 at 14:05
  • ty catch for main method not helping. Still the same. – senzacionale Oct 19 '11 at 04:59
  • And how about changing capability flag? – Renatas M. Oct 19 '11 at 05:33
  • I search in google but i do not know what capability flag means – senzacionale Oct 19 '11 at 11:30
  • Sorry I misspelled :) Its compatibility flag. In the [articles](http://msdn.microsoft.com/en-us/library/ms228965.aspx) bottom see section "Application Compatibility Flag" – Renatas M. Oct 19 '11 at 11:37
  • 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. – Bryce Wagner Jan 04 '18 at 17:24