General .NET question


  • Hello,

    Is there any way to make sure a .NET application does not crash no matter what errors are thrown?


    Tuesday, August 31, 2010 2:04 PM


All replies

  • You would need to write a flawless application which never executes any buggy code at any cost.

    You remind me my favourite catch line "Best function is the one which never executes".

    My next phone is Windows Phone 7
    Tuesday, August 31, 2010 2:35 PM
  • No. For instance, if your application throws a StackOverflowException, you'll be unable to recover from that state as these exceptions can't be caught by a try-catch (since .NET 2.0) and terminates the running process.


    Edit: I've just remembered of another unrecoverable action: Environment.FailFast() method will end your program immediatly. No way out of that. But this isn't likely to be an error in an application. If it happens, somebody meant for it to happen, so it really doesn't fit your scenario

    -- Blog:
    Tuesday, August 31, 2010 3:02 PM
  • One way is to encapsulate all command blocks into a try catch.



    // Try Catch
      // two int variables
      int a = 0;
      int b = -1;
      // if textBox1.Text is not an integer will throw a conversion error.
      int c = Convert.ToInt32(textBox1.Text);
      // this is just you throwing an exception maybe if a<>b
      throw new Exception("My very own error");
    catch(Exception x)
      // This will catch any error.
    This is what I do.
    Tuesday, August 31, 2010 3:03 PM
  • As several others have mentioned, you cannot trap *every* error. But you can trap most of them using a global exception handler.

    If you are using WinForms, I have a post on a global exception handler here:

    Hope this helps. ;
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    • Marked as answer by JFRonner Wednesday, September 01, 2010 7:11 AM
    Tuesday, August 31, 2010 3:09 PM
  • First of all, let me give the obligatory warning that you should never suppress unknown exceptions.  This can lead to memory leaks, corrupted application state, and a whole host of other problems.  For example, what happens if you get an exception that really should crash your app (e.g. OutOfMemoryException, StackOverflowException, ThreadAbortException)?  Having said all that, there is a way to catch and suppress every exception in an application, but it's a hack and I don't recommend it unless you have a very specific architecture requirement that calls for it.  

    As you probably already know, you can't just use the Application.ThreadException event in WinForms or the Application.DispatcherUnhandledException event in WPF because these events only catch exceptions that occur on the dispatcher thread.  The AppDomain.UnhandledException event is the only event that fires for exceptions on any thread, but it doesn't give you the ability to stop those exceptions from continuing to bubble up and crash your app.  You can't even wrap your entire Main() method in a try...catch block because this will only catch exceptions on the entry thread of your application.  So what do you do?

    The trick is to take advantage of a backward-compatibility switch that causes .Net to revert to the same error handling logic that was used in .Net 1.0 and 1.1.  Back in those versions, an unhandled exception in one AppDomain would cause that domain to crash, but any other AppDomains in the same process would continue running.  In .Net 2.0, they changed that behavior because it frequently led to corrupted application state, but they provided a switch for applications that relied on the old behavior.  To enable the switch, you have to add the following element to the <runtime> section of your App.config file:

    <legacyUnhandledExceptionPolicy enabled="1"/>

    After doing that, you can spawn a new AppDomain from your Main() method and run your entire application in that AppDomain.  Attach an event handler to the AppDomain.UnhandledException event, and whenever the event is triggered, just re-spawn the app in a new AppDomain.


    Tuesday, August 31, 2010 3:16 PM