Best Practice for Exception Handling in a Windows Forms Application?

Question

I\'m currently in the process of writing my first Windows Forms application. I\'ve read a few C# books now so I\'ve got a relatively good understanding of what language feat

Answer 1

I'm just on my way out but will give you a brief run down on where to use exception handling. I will attempt to address your other points when I return :)

1. Explicitly check for all known error conditions*
2. Add a try/catch around the code if your are unsure if you were able to handle all cases
3. Add a try/catch around the code if the .NET interface you are calling throws an exception
4. Add a try/catch around the code if it crosses a complexity threshold for you
5. Add a try/catch around the code if for a sanity check: You are asserting THIS SHOULD NEVER HAPPEN
6. As a general rule, I do not use exceptions as a replacement for return codes. This is fine for .NET, but not me. I do have exceptions (hehe) to this rule though, it depends on the architecture of the application your are working on as well.

*Within reason. There is no need to check to see if say a cosmic ray hit your data causing a couple bits to get flipped. Understanding what is "reasonable" is an acquired skill for an engineer. It's hard to quantify, yet easy to intuit. That is, I can easily explain why I use a try/catch in any particular instance, yet I am hard pressed to imbue another with this same knowledge.

I for one tend to steer away from heavily exception based architectures. try/catch doesn't have a performance hit as such, the hit comes in when the exception is thrown and the code might have to walk up several levels of the call stack before something handles it.

Answer 2

I like the philosophy of not catching anything I don't intend on handling, whatever handling means in my particular context.

I hate it when I see code such as:

try
{
   // some stuff is done here
}
catch
{
}

I have seen this from time to time and it is quite difficult to find problems when someone 'eats' the exceptions. A coworker I had does this and it tends to end up being a contributor to a steady stream of issues.

I re-throw if there is something that my particular class needs to do in response to an exception but the problem needs to be bubbled out to however called the method where it happened.

I think code should be written proactively and that exceptions should be for exceptional situations, not to avoid testing for conditions.

Answer 3

you can trap the ThreadException event.

1. Select a Windows Application project in Solution Explorer.

2. Open the generated Program.cs file by double-clicking on it.

3. Add the following line of code to the top of the code file:

   using System.Threading;
   

4. In the Main() method, add the following as the first line of the method:

   Application.ThreadException += new ThreadExceptionEventHandler(Application_ThreadException);
   

5. Add the following below the Main() method:

   static void Application_ThreadException(object sender, ThreadExceptionEventArgs e)
   {
       // Do logging or whatever here
       Application.Exit();
   }
   

6. Add code to handle the unhandled exception within the event handler. Any exception that is not handled anywhere else in the application is handled by the above code. Most commonly, this code should log the error and display a message to the user.

refrence: https://blogs.msmvps.com/deborahk/global-exception-handler-winforms/

Answer 4

Exceptions are expensive but necessary. You don't need to wrap everything in a try catch but you do need to ensure that exceptions are always caught eventually. Much of it will depend on your design.

Don't re-throw if letting the exception rise will do just as well. Never let errors pass unnoticed.

example:

void Main()
{
  try {
    DoStuff();
  }
  catch(Exception ex) {
    LogStuff(ex.ToString());
  }

void DoStuff() {
... Stuff ...
}

If DoStuff goes wrong you'll want it to bail anyway. The exception will get thrown up to main and you'll see the train of events in the stack trace of ex.

Answer 5

When re-throwing an exception the key word throw by it self. This will throw the caught exception and still will be able to use stack trace to see where it came from.

Try
{
int a = 10 / 0;
}
catch(exception e){
//error logging
throw;
}

doing this will cause the stack trace to end in the catch statement. (avoid this)

catch(Exception e)
// logging
throw e;
}

Answer 6

Note that Windows Forms has it own exception handling mechanism. If a button in form is clicked and its handler throws an exception which isn't caught in the handler, Windows Forms will display its own Unhandled Exception Dialog.

To prevent the Unhandled Exception Dialog to be displayed and catch such exceptions for logging and/or for providing your own error dialog you can attach to the Application.ThreadException event before the call to Application.Run() in your Main() method.