views:

70

answers:

3

For many methods in .NET, the exceptions they can potentially throw can be as many as 7-8 (one or two methods in XmlDocument, Load() being one I think, can throw this many exceptions).

Does this mean I have to write 8 catch blocks to catch all of these exceptions (it is best practise to catch an exception with a specific exception block and not just a general catch block of type Exception).

How do I use this information?

Thanks

+3  A: 

In general, do not catch the exception unless you can do something about it. Let it bubble up to the caller. If you want to catch the exception just for information purposes, then you can rethrow it again:

try
{
    // some code
}
catch (SomeSpecificExceptionThanYouCanHandle ex)
{
    // This is an exception I can do something about
    // so I'll do something intelligent
}
catch (Exception ex)
{
    Logger.Error("Exception in SomeMethod: " + ex.Message);
    throw;
}

So, if you call a method that may throw one of 8 different exception types, add catch blocks for those that you can handle, and leave the others for the caller to deal with. If you are writing a class library (and probably otherwise as well), don't forget to document what exceptions your method may throw.

This is not quite true at the "top-level" of your application. An event handler for a button click should never make the application crash in an uncontrolled manner; here you will need to gracefully try to do something; catch the exception, log it, tell the user that things did not work out and perhaps (if necessary) shut down the application.

Fredrik Mörk
A: 

Catching exceptions simply is one method to control the flow of your program. You are correct in stating that in general catching specific exceptions is better than trapping more generic exception types (all the way up to Exception), but that does not mean it makes sense to trap all exceptions. Certain exceptions should not be trapped at all; in such a situation, you should have some error reporting system that informs you of such truly exceptional behavior.

I tend to catch exceptions for which I can provide some recourse. So I will catch specific exceptions where I can either provide some useful information to the user (or caller) or when it makes sense to execute some additional logic. But oftentimes it is best to let certain exceptions not be handled at all. Many .NET exceptions - such as ArgumentNullException - exist to inform the programmer of a programming error, not the user of some incorrect behavior.

mcliedtk
A: 

Yes, best practice is to have many catches, and not use the general exception, tools like fxcop will confirm this when analyzing your code. In practice i seen mostly 2-3 catches.

You could look in your object explorer to see from which class derives your exception and catch the parent exception instead of all 8 possible exception.

Practically, look at what can fail in the way you are currently using the object, very often only one or two exceptions are likely to happen, then you can follow it up with a general one.

Catching exceptions should not be used to control flow, it should be used to handle a situation where your method dosen't have what it needs to do it's work successfully.

Inside the catch you will generally write to either a log file or the system's event log. You'd write something like

string message = "Error when retrieving product from database. The system reports: ex.Message"

or

string message = "Error when retrieving product from database"

if(ex.Number == 20) { message = message + " This likely indicates that a connection to the database could not be established" }

message = message + ". The system reports: ex.Message"

GenEric35