Jim Rogers

Lives in Baton Rouge, LA, with two dogs, one cat, and one lovely wife. I'm a lead developer for GCR & Associates.

Katrin and Jim

Month List

WPF Worker Thread Exceptions

by Jim Jun 23, 2008 8:37 PM

What if you want to do global exception handling with worker threads? My scenario involves data methods that may be called synchronously, on the UI thread, or asynchronously on a worker. I would like to use the same global exception handling for both.

The problem with this scenario is that unhandled exceptions in the worker thread may cause the application to terminate; there's no handler you can use or flag you can set to prevent this.

One way of handling this is explained as a side note in MSDN's Application.DispatcherUnhandledException documentation:

  1. Handle exceptions on the background thread.
  2. Dispatch those exceptions to the main UI thread.
  3. Rethrow them on the main UI thread without handling them to allow DispatcherUnhandledException to be raised.

I guess they thought the code was too obvious to bother providing an example...

That list is mentioned in the MSDN forums, where an example was promised, but not delivered.

try
{
    . . . 
}
catch (Exception ex)
{
    . . . 

    // Are we not on the main UI thread?
    if (!Application.Current.Dispatcher.CheckAccess())
    {
        // Unhandled exceptions on worker threads will halt the application. We want to
        // use our global exception handler(s), so dispatch or "forward" to the UI thread.
        Application.Current.Dispatcher.Invoke(
            System.Windows.Threading.DispatcherPriority.Normal,
            new Action<Exception>(WorkerThreadException), ex);
    }
    else
    {
        throw;  // Already on UI thread; just rethrow the exception to global handlers
    }
}

The WorkerThreadException method simply re-throws the exception on the UI thread, where it is handled by any global exception handlers that have been defined:

private static void WorkerThreadException(Exception ex)
{
    throw ex;
}

Tags:

Code

Comments (3) -

7/7/2011 1:04:08 PM #

Tim A

Thanks very much, this is exactly what I was trying to find.

Tim A United States

9/20/2011 9:45:31 PM #

Boris

I think that WorkerThreadException implementation is not correct: when you rethrow exception in that way(throw ex) all the stack trace is trimmed and exception handler will not see the real source of exception, only your WorkerThreadException method call. So, it to wrap "ex" in other exception to preserver stack trace...

...Just another .net framework limitation :(

Boris Russia

9/21/2011 6:13:06 AM #

Jim

Boris, you have a good point about the stack trace - but you can only re-throw an exception with a naked "throw" statement from within a catch block, so I'm pretty sure it wouldn't work here.

Maybe a better solution would be to derive a WorkerThreadException class from Exception, and rethrow like this:
throw new WorkerThreadException("Exception in worker thread A", ex)

Jim United States

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading