Why shouldn't I catch general exceptions?

[john_c]

FxCopy says this about catching general exceptions:

"You should not catch Exception or SystemException.
Catching generic exception types can hide run-time
problems from the library user, and can complicate
debugging. You should catch only those exceptions that
you can handle gracefully."

This is for a winform app but applies to asp.net also. There are some
code blocks you may know which exception may get thrown and others
that you are unsure. I guess FxCop is saying to just put in several
catches for specific exceptions. However, what if you guess wrong?

I currently write general exceptions into the Event Log. Why would
that not be a good way to go?

I'm not familiar with coding a robust try/catch/finally blocks. If
you put in the specific exception, say IOException, and your code
block happens to throw and argument exception, what then? If you
didn't do anything anywhere else, that goes straight up to the user
and crashes the app (winforms). What are the recommendations for
handling this?

Thanks,
John

 

[John Timney \(MVP\)]

My personal opinion is that you should catch all exceptions gracefully, but
make sure the user is informed that an error has occured. The reason it
states it speciifically for libraries is likely to be that a library is an
object thats consumed, so its up to the consumer to determine what to do
with any thrown error. With a library, its normally a coder developing code
that uses the library, so they should handle any exception thrown to them.


Regards

John Timney (MVP)
http://www.johntimney.com
http://www.johntimney.com/blog

 

[Mark Rae]

My personal opinion is that you should catch all exceptions gracefully,
but make sure the user is informed that an error has occured. The reason
it states it speciifically for libraries is likely to be that a library is
an object thats consumed, so its up to the consumer to determine what to
do with any thrown error. With a library, its normally a coder developing
code that uses the library, so they should handle any exception thrown to
them.

Yes indeed...

Generally speaking, I catch all exceptions in base classes because I don't
want a crash, but don't handle them there - I simply throw them back to the
calling method which decides what to do next...

 

[Mark Fitzpatrick]

John,
It just means to try to catch specific ones first. The more specific
an error you can catch then the more useful your response to the user will
be. For example, if you were creating a user and something went wrong, you
would want to let the user know that there was an issue with their password,
or that a user had already registered with that username as opposed to a
real failure due to the database being offline. Catching general exceptions
is fine, but usually after you've tried to catch the more specific
exceptions to the code you are writing.

Keep in mind, you'll want to avoid lots of nested try/catch blocks
unless where necessary as each try/catch block will result in a slight
performance hit. In high-volume sites this can become more noticeable.

 

[John Saunders]

Yes indeed...

Generally speaking, I catch all exceptions in base classes because I don't
want a crash, but don't handle them there - I simply throw them back to
the calling method which decides what to do next...

If you're going to throw it back to the calling method, then why catch it at
all?

John

 

[Mark Rae]

If you're going to throw it back to the calling method, then why catch it
at all?

Because if I don't the app will crash...

 

[John Saunders]

Because if I don't the app will crash...

I'm sorry, but that makes no sense. What you'd be doing by not catching it
is exactly the same as what would happen if you catch it and then rethrow
it.

Perhaps we're not talking about the same thing. Could you provide a code
example?

And please tell us what you mean when you say "the app will crash".

Johnm