19

I have a WPF application that spins off several threads. I have defined a DispatcherUnhandledException event handler in App.xaml.cs that displays a detailed error message, and this handler gets called every time the UI thread encounters an exception. The problem is with the child threads: their unhandled exceptions never get handled. How do I do this?

Sample code:

private void Application_DispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
{
    MessageBox.Show("detailed error message");
}

private void Application_Startup(object sender, StartupEventArgs e)
{
    //...
    //If an Exception is thrown here, it is handled
    //...

    Thread[] threads = new Thread[numThreads];
    for(int i = 0; i < numThreads; i++)
    {
        threads[i] = new Thread(doWork);
        threads[i].Start();
    }
}

private void doWork()
{
    //...
    //Exception thrown here and is NOT handled
    //...
}

Edit: Once an unhandled exception occurs, I want to display an error message with a stack trace, and then exit the application.

Phil
  • 6,561
  • 4
  • 44
  • 69

2 Answers2

18

Try hooking up to the AppDomain.CurrentDomain.UnhandledException event as well.

Brandon
  • 68,708
  • 30
  • 194
  • 223
  • 1
    See http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx to read why this should only be used to log the error before exiting. – H H Sep 15 '09 at 18:13
  • @Henk, thats the same link I already posted. You are right though, the exception should only be used for logging purposes. – Brandon Sep 15 '09 at 21:14
  • Brandon, OK, I didn't check your link (-: But it follows that every Thread should handle it's own exceptions. – H H Sep 15 '09 at 22:05
3

This is by design, you should use a try/catch at the top-level of DoWork. Some threading models cater for this, take a look at the Backgroundworker for an example.

The .NET 4 Task class provides a nice interface to this problem. Until then, you will have to take care of it yourself, or use the BGW or IAsyncResult models.

H H
  • 263,252
  • 30
  • 330
  • 514
  • That is a very valid answer, but for my particular situation I happen to be running a long, complex process in doWork(). From what I understand, try/catch blocks impose a pretty decent performance penalty, and I prefer to use them only on small chunks of code. – Phil Sep 15 '09 at 19:24
  • 4
    No, try/catch only affects performance _when_ an exception is thrown, and then speed is usually not your biggest problem. In the normal case there is no drawback. And after an exception 'escapes' from a thread, the stability of your entire app is in question. – H H Sep 15 '09 at 20:25