This post originated from an RSS feed registered with .NET Buzz
by Tim Sneath.
Original Post: The Exception Back Stop
Feed Title: Tim Sneath's Blog
Feed URL: /msdnerror.htm?aspxerrorpath=/tims/Rss.aspx
Feed Description: Random mumblings on Microsoft, .NET, and other topics.
One of my Paris-based colleagues, Nigel Watling, regularly posts insightful nuggets
of information to an internal distribution list he's responsible for. I suggested
he start a blog back at TechEd last year, since he's got enough material to make it
really interesting. In the meantime, he pointed out a really useful sample that should
be mandatory for any professional Windows Forms application, and I've shamelessly
plagiarised his supporting text as it's very useful...
He points out that when handling exceptions in WinForms, there will inevitably be
some (unknown) exceptions that you do not handle in your error handling code for the
form. This is guaranteed due to the non-linear nature of WinForms. To handle these
you should register your own handler with the Windows Forms API using the Application.ThreadException event.
Doing this suppresses the informational (but less professional) debug dialog that
comes up by default.
This only works, however, for the thread that is pumping GUI messages, and so you
will still have to rely on the CLR unhandled exception handler for all other exceptions
(finalizer thread, thread-pool thread, manual thread, etc.). You can register for
this handler using the AppDomain.UnhandledException event.
Previous Topic
