FxCop warnings about general catch clauses ...

[Guest]

I have some general catch clauses in my app as follows:

try
{
}
catch(Exception ex)
{
}

try
{
}
catch(Exception ex)
{
}

try
{
}
catch(SystemException ex)
{
}

I analyzed the code with Microsoft FxCop.
The FxCop warned me that "Generic exceptions should not be caught".
Could anyone explain what is wrong with usage of general catch clauses?
Thanks.

 

[Manish Soni]

What I understood from the descrition of FxCop error is that if you catch
the general exception(Exception),
then even if the error is a system level error for example
OutOfmemoryException, your code will catch it even when
it can not handle the exception and take corrective steps.

Instead if this exception was not caught and went up to system level, then
system software can take some
corrective action.

So basically it says you should only catch what you can handle and you
expect your code to throw.

I hope this helps.

Manish Soni

 

[David Browne]

I have some general catch clauses in my app as follows:

try
{
}
catch(Exception ex)
{
}

try
{
}
catch(Exception ex)
{
}

try
{
}
catch(SystemException ex)
{
}

I analyzed the code with Microsoft FxCop.
The FxCop warned me that "Generic exceptions should not be caught".
Could anyone explain what is wrong with usage of general catch clauses?

FxCop is wrong. You can catch Exception, you just can't eat it. It's a
Catch and Release only item.

Generic exceptions should often be caught, but they shoud usually be
rethrown or wrapped and rethrown.

You might catch Exception in order to capture stack data (arguments) which
will dissappear when the exception propagates back up the stack.

eg:

void foo(string s)
{
try
{
..do domething
}
catch(Exception ex)
{
throw new MyAppException("foo failed with argument s=" + s,ex);
}
}

or

void foo(string s)
{
try
{
..do domething
}
catch(Exception ex)
{
Trace.WriteLine("foo failed with argument s=[" + s + "] because " +
ex.Message);
throw;
}
}


There are many situations where it is inappropriate or unnecessary to catch
Exception, but it's not a general rule. If you are running a SqlCommand,
you should catch SqlException, not Exception. And you should never catch
Exception and then try to recover. Exception includes things like
ExecutionEngineExeption, OutOfMemoryException, ThreadAbortException and
StackOverflowException. You should never try to recover from these.


David

 

[Nicole Calinoiu]

Steve,

The design guidelines implemented as FxCop rules are intended mainly for
library assemblies. Although most are perfectly applicable to "end"
applications, some aren't. This happens to be one of them. Basically, the
rule is meant to prevent library authors from suppressing exceptions that
should be thrown up to the application that is using the library.

It's perfectly acceptable to exclude violations of this rule under the
following circumstances:
1. You're writing a "end" application, and your catch block is being used
to handle exceptions that have nowhere else to go by, for example,
displaying exception information to the user or logging the exception
details.

2. You're writing a library application and your catch block either...
a. rethrows the exception with a simple "throw;" (not "throw ex;"),
or
b. throws a new exception whose inner exception is the caught
exception.

HTH,
Nicole