title: Why do AppDomain exceptions invariably terminate the application?
body: <p>This is related to a <a href="https://stackoverflow.com/questions/1301153/using-threadexceptioneventhandler-determine-which-thread-caused-the-exception">previous question</a>.</p>
  
  <p>What I'm trying to understand now is how come UI thread exceptions can be prevented from terminating the application while non-UI exceptions can't be.</p>
  
  <p>For reference, see <a href="http://msdn.microsoft.com/en-us/library/system.windows.forms.application.threadexception.aspx" rel="nofollow noreferrer">this example</a>.</p>
  
  <p>Most importantly, what I would like to be able to do in that case is "silently" terminate the process--without displaying the Windows dialog box that asks whether I'd like to send an error report or not.</p>
  
  <p>This is my AppDomain UnhandledExceptionHandler:</p>
  
  <pre><code>private static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
  {            
      try
      {
          // Maybe do some logging here if allowed
      }
      catch
      {
      }
  
      // then just terminate the application
      Application.Exit();            
  }
  </code></pre>
  
  <p><strong>UPDATE</strong><br>
  In light of comments in <a href="https://stackoverflow.com/questions/1301292/why-do-appdomain-exceptions-invariably-terminate-the-application/1301333#1301333">this answer</a>, I'd like to clarify that most importantly I'd like to find out more about the mechanism that enables the UI thread to have an early opportunity to catch unhandled exceptions via the <code>Application.ThreadException</code> mechanism. And whether such behavior could be implemented on a non-UI thread.</p>