views:

527

answers:

4

Short of inserting a try/catch block in each worker thread method, is there a way to deal with unhandled, non-ui thread, exceptions in Windows Forms?

Thread.GetDomain().UnhandledException works great for catching the error, but by then it's too late to do anything about it (besides log it). After control passes out of your UnhandledException handler the application will terminate. The best you can hope for is a generic Windows error that looks this:

http://i40.tinypic.com/2be98i.jpg

All my research indicates that you must insert a try/catch block in the worker thread method, but I wanted to put this out there in case anyone had a different take.

Thanks.

+2  A: 

If you want to do something about the error before it hits UnhandledException, then you need a try/catch in the thread method.

You should at least handle exceptions like FileNotFoundException here, where you can do something intelligent about it. If all else fails, you can use UnhandledException to cleanly handle anything you didn't expect (which, hopefully, is nothing).

Jon B
A: 

It sounds like you misunderstand... You don't put code "into" a thread. You run code "on" a thread.

Wherever you put the try catch block, it can end up being executed on any thread... if you want the code in the catch to do something (manipulate) a UI element, you simply need to "Run" that code on whatever thread the UI elements were created on (if necessary).

Every WinForms UI Element has two members to help you with this, InvokeRequired(), which returns a boolean if it is being executed on any thread OTHER than the thread the element was created on (in which case you must switch threads), and BeginInvoke() which automatically switches to the correct thread.

Charles Bretana
Right. I probably should have been clearer. When I write 'worker thread method' I'm talking about the code that will execute when the thread starts. It's not such much a 'UI thread' to 'Worker thread' *switching* question as it is an error handling question. Thanks.
Eric Tobia
no prob, good luck!
Charles Bretana
+1  A: 

Thread.GetDomain().UnhandledException devolves to AppDomain.UnhandledException, which ordinarily would be the same domain for all threads in your application - in other words, you only have to hook this event once, not once per thread.

unhandled exceptions in secondary threads will kill the thread. see SafeThread for an alternative

caveat: i am the author of the SafeThread article

Steven A. Lowe
A: 

To handle the exception, you must insert a try/catch block inside the code that is executing within the thread.

If you think about it, the UnhandledException is actually well named. The exception was 'not handled' and therefore you can't do anything about it. Too late!

And really, outside of a thread's context, there's not much that you can do to 'save' it from crashing since you have no context in which to correct. So the UnhandledException is useful for logging and trying to determine why something crashed after it crashes.

If you think about how try/catch works:

try
{
  // run this code

}
catch (Exception ex)
{
  // an exception happened in the above try statement inside MY thread
}
Craigger