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

Question

Alright, this is an easy one:

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

• Do I need to handle both?

Thanks!

Answer 1

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.

Answer 2

From source:

In applications that use Windows Forms, unhandled exceptions in the main application thread cause the Application.ThreadException event to be raised. If this event is handled, the default behavior is that the unhandled exception does not terminate the application, although the application is left in an unknown state. In that case, the UnhandledException event is not raised. This behavior can be changed by using the application configuration file, or by using the Application.SetUnhandledExceptionMode method to change the mode to UnhandledExceptionMode.ThrowException before the ThreadException event handler is hooked up. This applies only to the main application thread. The UnhandledException event is raised for unhandled exceptions thrown in other threads.

Starting with Visual Studio 2005, the Visual Basic application framework provides another event for unhandled exceptions in the main application thread - WindowsFormsApplicationBase.UnhandledException. This event has an event arguments object with the same name as the event arguments object used by AppDomain.UnhandledException, but with different properties. In particular, this event arguments object has an ExitApplication property that allows the application to continue running, ignoring the unhandled exception (and leaving the application in an unknown state). In that case, the AppDomain.UnhandledException event is not raised.

Application.ThreadException can be caught and the application could continue (in general is not a great idea, but for the application like running periodically some actions this is a good solution).

To catch exceptions that occur in threads not created and owned by Windows Forms, use the AppDomain.UnhandledException. It allows the application to log information about the exception before the system default handler reports the exception to the user and terminates the application.
The handling of this exception does not prevent application to be terminated.
The maximum that could be done(program data can become corrupted when exceptions are not handled) is saving program data for later recovery. After that the application domain is unloaded and the application terminates.

Starting with the .NET 4, this event is not raised for exceptions that corrupt the state of the process, such as stack overflows or access violations, unless the event handler is security-critical and has the HandleProcessCorruptedStateExceptionsAttribute attribute.

For more details, see MSDN.