In a Winforms C# application, it seems like a good idea to catch exceptions in the GUI event methods such as button clicks, since this where all user action in an application begins.
If I put try-catch-finally clauses in the event methods then surely all my exceptions can be caught and dealt with appropriately?
Right?
In general, you should only catch exceptions that you know how to actually handle. You should catch them as close as possible to where they occur (because at that point, you know what the exception actually means).
If you are only catching exceptions in order to log them (and if this is a WinForms application), then I would use the Application.ThreadException event.
There are several ways to do it..
I prefer creating my error handler and throw all the exceptions from the code instead of catching it at that level.
Look at another post on how to handle them via Global Handler:
yes your are. but Exception is for, Catch specific exception to general exception.
[updated] If exception is from different thread then it won't . right point, thanks " Brian Rasmussen" ;)
catches should be placed as close to the throwing source as possible. If your button click calls into your business layer which does some file processing, the business layer will better know how to recover from a FileNotFoundException than your button click handler.
Please check http://msdn.microsoft.com/en-us/library/system.windows.forms.application.threadexception.aspx
public static void Main(string[] args){
// Add the event handler for handling UI thread exceptions to the event.
Application.ThreadException += new ThreadExceptionEventHandler(ErrorHandlerForm.Form1_UIThreadException);
// Set the unhandled exception mode to force all Windows Forms errors to go through
// our handler.
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
// Add the event handler for handling non-UI thread exceptions to the event.
AppDomain.CurrentDomain.UnhandledException +=
new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
// Runs the application.
Application.Run(new ErrorHandlerForm());}
Typically, the best advice is to catch exceptions where they can best be handled, and generally to favor catching them earlier if possible.
The reason is that an exception represents an error state that the code throwing it does not know how to deal with (if it did, then it would have dealt with the error). As a simple example, say you throw a NullReference exception. The coding throwing has no idea why the reference it needs is null. Maybe it's supposed to be, but the code doesn't account for it. Or maybe there's an error in your logic farther up that passes the null down.
Catching everything at the highest level, the UI events, is a good fallback to prevent exceptions from being exposed to the user, but it's a bad practice to get accustomed to because it obscures the real reasons why exceptions are being thrown and makes it difficult to figure out where the error should be corrected at.
A try block will operate on any uncaught exceptions thrown by code within the try block. This includes methods you call, any methods those methods call, and so on. If the exception is thrown from one of those methods, it will "bubble up" through the program, breaking out of loops, methods, etc. until it reaches the last (i.e. deepest) try block to enclose it.
You could say that from the time you enter the try block until the time you leave it, any exceptions will immediately break out of the try and have the opportunity to be handled by it (unless they're caught by other try blocks nested inside it).
So to answer your question, if you know any exceptions are going to happen inside the event handler (or in methods called from inside that event handler), then wrapping the whole thing inside a try-catch-finally block will catch any exceptions (assuming an untyped catch).
Whether this is a good idea or not is a question of design. It usually isn't. You normally want to put your error-handlers fairly close to where the error might get thrown. However, without knowing your situation or your code, it's hard to give you any advice on design details like this.
Not to forget AppDomain.UnhandledException. I always handle this one, too, when doing central exception handling.
