What's the Difference Between Application.Threadexception and Appdomain.Currentdomain.Unhandledexception

What's the difference between Application.ThreadException and AppDomain.CurrentDomain.UnhandledException?

Application.ThreadException is specific to Windows Forms. Winforms runs event handlers in response to messages sent to it by Windows. The Click event for example, I'm sure you know them. If such an event handler throws an exception then there's a back-stop inside the Winforms message loop that catches that exception.

That backstop fires the Application.ThreadException event. If you don't override it, the user will get a ThreadExceptionDialog. Which allows him to ignore the exception and keep running your program. Not a great idea btw.

You can disable this behavior by calling Application.SetUnhandledExceptionMode() in the Main() method in Program.cs. Without that backstop in place, the usual thing happens when a thread dies from an unhandled exception: AppDomain.UnhandledException fires and the program terminates.

Fwiw: "ThreadException" was a very poor name choice. It has nothing to do with threads.

Application.ThreadException vs AppDomain.UnhandledException

Yes, Application.ThreadException can only trap exceptions that are raised in the UI thread. In code that's run due to Windows notifications. Or in technical terms, the events that are triggered by the message loop. Most any Winforms event fit this category.

What it does not trap are exceptions raised on any non-UI thread, like a worker thread started with Thread.Start(), ThreadPool.QueueUserWorkItem or a delegate's BeginInvoke() method. Any unhandled exception in those will terminate the app, AppDomain.UnhandledException is the last gasp.

Going further down-hill, hardware exceptions that are raised in an unmanaged thread by native code that never made any managed CLR call can not be detected with any CLR mechanism. An AccessViolation (exception code 0xc0000005) is the most common cause of death. The only way to trap those is through the Windows API, SetUnhandledExceptionFilter(). This is hard to get right.

You can disable Application.ThreadException with Application.SetUnhandledExceptionMode(). Which is a wise thing to do, giving the user the Continue option doesn't make a lot of sense. Now all exceptions in managed threads behave the same, use AppDomain.UnhandledException to log them.

Suppressing Application.ThreadException and AppDomain.CurrentDomain.UnhandledException

As it's windows forms app Application.ThreadException is used for unhanded exception: "This event allows your Windows Forms application to handle otherwise unhandled exceptions that occur in Windows Forms threads. Attach your event handlers to the ThreadException event to deal with these exception" (MSDN)

I think you must expect such behavior as at UIThreadExceptionHandler you have Application.Exit(new CancelEventArgs(true)). Exit methods description: "Informs all message pumps that they must terminate, and then closes all application windows after the messages have been processed." (MSDN)

AppDomain.CurrentDomain.UnhandledException event is used to handle non-UI thread exceptions.

EDIT 1:

AppDomain.CurrentDomain.UnhandledException is specifically designed to log an exception before the system will inform a user and terminates the process. You can not prevent terminating the process (unless you are using Net 1.1).

Application.ThreadException + UnhandledExceptionMode.CatchException
allows you to keep your UI thread alive. But, it's really not a great idea. It's much better to enclose error prone code in try-catch blocks instead.

Thus if you want to catch exceptions coming from thread and keep your application alive, you have to do it inside using try-catch block.

You haven't issue with UnhandledExceptionHandler, because it's not fired at all, I suppose.

Difference between UnhandledException and DispatcherUnhandledException in .NET

Application.DispatcherUnhandledException will handle exceptions thrown on the main UI thread in a WPF application. AppDomain.UnhandledException will handle exceptions thrown on any thread and never caught. This includes threads you create manually or the main thread in a Console application. WPF is catching the exceptions on the UI thread, so you will not see those in AppDomain.UnhandledException.

Also note that unhandled exceptions typically terminate the runtime, so after AppDomain.UnhandledException is raised your program will immediately exit. In contrast, Application.DispatcherUnhandledException is catching exceptions and will let your program continue.

AppDomain UnhandledException

Assuming that all of your projects are running in the same appdomain, this will work correctly. We have this exact code encapsulated in a common DLL that is shared among numerous applications.

An additional suggestion: if this is used in Windows Forms applications, you probably also want to add a handler for System.Windows.Forms.Application.ThreadException. This serves as a backstop when, for example, someone forgets to add exception handling to a control event.

Exception getting past Application.ThreadException and AppDomain.CurrentDomain.UnhandledException

Just shooting in the dark here - is it possible that the ArgumentOutOfRangeException is actually thrown from your exception handler?

Additionally, you didn't say what type of application is in question -- Application.ThreadException only affects WinForms threads, so if this isn't a GUI application it's useless. (See the remarks section in the MSDN documentation)

CurrentDomain.UnhandledException is not being thrown in Windows Service

It is probably that your throwing code is before use set AppDomain.CurrentDomain.UnhandledException or because you put it in OnStart method

Second option is because it is ThreadException.

Bot above problems were discussed before in following threads:

1. How can I set up .NET UnhandledException handling in a Windows service?
2. Global exception handler for windows services?

---

Related Topics