Order in Chaos: Handling unhandled exceptions in a WPF application

introduction

so you want to handle somehow all the unhandled exceptions in your application.
usually you want to accomplish one of the following:

• log the exception for later diagnostics
• present the user an unhandled exception ui, nicer than the default

you heard there’s an event you should register, or maybe you find one by mistake, but is it the correct one?

did you know there are four (!) different events for handling unhandled exceptions in the .net framework?

so what is the difference between them and when should we use each one?
this post will hopefully answer these questions.

note: this is not a replacement for try-catch blocks!

summary

i’ll begin with the summary to avoid boring busy developers.

in a typical wpf application you should use application.current.dispatcherunhandledexception for exceptions generated on the ui thread and appdomain.currentdomain.unhandledexception for all the other exceptions.

now, for the details..

system.windows.forms.application.threadexception

this event is used for catching unhandled exceptions only on ui threads created by winforms . other exceptions, generated on non-ui threads won’t arrive to this event. use appdomain.current.unhandledexception to catch them.

the default behavior of a winforms application with an unhandled exception is to present the following error dialog:

if you register to this event, the application will not show the error dialog and will automatically extend the application life (i.e. the application won’t be killed).

if you do want to end your application, maybe after logging the exception or asking the user with a personalized dialog, you must do it yourself using application.exit() .

you can find the msdn documentation on this event here .

system.windows.application.current.dispatcherunhandledexception

this event is used for catching unhandled exceptions only from the main ui thread created by wpf .

the default behavior of a wpf application with an unhandled exception is to present the following error dialog and end the application:

if you register to this event, you will get the chance to log the exception, but the application will still end, unless you set e.handled = true , on the event’s eventargs parameter.

you can find the msdn documentation on this event here .

dispatcher.unhandledexception

this event is used for catching unhandled exceptions on the thread attached to the specific dispatcher (wpf only). note, that in wpf two threads can have two different dispatcher object attached. this event is only useful if you have several ui threads in your wpf application, which is quite rare. if you’re not sure, you probably need to handle only the previous event: application.current.dispatcherunhandledexception.

as in the previous event, if you register, you will get the change to log the exception. to prevent the exception internal handling from being called set e.handled = true .

you can find the msdn documentation on this event here .

appdomain.currentdomain.unhandledexception

this event is used for catching unhandled exceptions generated from all threads running under the context of a specific application domain.

you can find the msdn documentation on this event here .

bonus: appdomain.currentdomain.firstchanceexception

this event which exists only from .net 4, is raised on any exception, if the handled one. in fact, the event is raised before the search for the catch blocks. you can’t handle the exception using this event. you can use it if you need to log exceptions that are caught.

you can find the msdn documentation on this event here .