views:

193

answers:

6

I read a lot about how bad catching base Exceptions is and I have to confess that I did it also:

try{
    ...
}
catch (Exception exception){
    MessageBox.Show(exception.Message, "Error!");
    MyLogger.Log(exception.Message);
}

Now I would like to do it right and have some questions about it:

  1. Which exceptions should I catch (for example FileNotExists for file manipulation, but what for TableAdapter or ReportClass (CrystalReports))
  2. Where can I see a list of exceptions, that an objects can throw (for example TableAdapter)
  3. Where in Windows Forms Application can I set a static method, which will log any exception to a file for example
  4. Any other suggestions?

Thanks!

+1  A: 

You should only catch exceptions you can do something about, really.

That's the rule of thumb. I typically have a try/catch around my Program.Main just in case an exception bubbles right to the top and needs logging. You can also handle the CurrentDomain_UnhandledException event, in case exceptions are thrown in other threads than the UI thread (assuming you are multithreading).

Neil Barnwell
+7  A: 
  1. Catch whichever exceptions you can reasonably handle. For example, if you're trying to open a file for writing, you should expect that maybe the file is marked read-only, so that would throw an exception. But in the same situation you wouldn't try to catch a null argument exception, because that would be due to programmer error.

  2. They should be found in the function reference in MSDN (you'll have to look it up on each one). For user-defined functions, you'll have to go digging, unless there is additional documentation or summary commentary.

3, 4. Consider using a logging library for .NET

Jon Seigel
I agree with all of these points. I'll also add to point 2 that for your own methods which throw exceptions, it's important to document which exception is thrown in which case so that callers know how to handle it.
Meta-Knight
+2  A: 
  1. That's up to you to decide which exceptions your application logic can reasonably expect to recover from.
  2. Exceptions are thrown by method invocations, not objects. In Visual Studio, Intellisense explanations will tell you which exceptions are thrown by an object (provided that the XML documentation describes which exceptions a method throws.
  3. Rather than use a static method, respond to the Application.ThreadException event. The link provided has examples. MSDN
Alex
+4  A: 

I have one thing to add. If you just want to log an exception without affecting program flow you can always do this:

try
{   
    ...
}
catch (Exception exception)
{    
   MyLogger.Log(exception.Message);

   throw;
}
unclepaul84
+1 This is a good supplementary technique.
Jon Seigel
+2  A: 

You can set an event for unhandled exceptions in application events file

(got a VB sample here but i hope you get the point)

Private Sub MyApplication_UnhandledException(ByVal sender As Object, ByVal e As Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs) Handles Me.UnhandledException

    End Sub

You can find the application events in the options of you project.

Ivo
A: 

In response to "4. Any other suggestions?":

In your example code, a message box is displayed before logging the exception. I would recommend logging the exception before displaying the message, just in case the user sees the error message, panics, and goes on vacation without clicking "OK". It's a minor thing, but message boxes block the program indefinitely and should be used with discretion!

Jeffrey L Whitledge