Avoiding Catching System.Exceptio n

[cmay]

FxCop complains every time I catch System.Exceptio n.
I don't see the value in trying to catch every possible exception type
(or even figuring out what exceptions can be caught) by a given block
of code, when System.Exceptio n seems to get the job done for me.
My application is an ASP.Net intranet site. When I catch an exception,
I log the stack trace and deal with it, normally by displaying an error
page to the user.

What do I gain by catching a specific exception?

Is there any "easy" way to figure out the possible exceptions that
could be thrown by a given block of code?

Pretty much any block of code that interacts w/ the database and
databinds some information could throw a who slew of possible
exceptions. Does anyone really list out every exception type that
could be thrown in this sitution, as FxCop is saying I should?

[allan_w]

cmay wrote:

FxCop complains every time I catch System.Exceptio n.

I don't see the value in trying to catch every possible exception type
(or even figuring out what exceptions can be caught) by a given block
of code, when System.Exceptio n seems to get the job done for me.

My application is an ASP.Net intranet site. When I catch an exception,
I log the stack trace and deal with it, normally by displaying an error
page to the user.

What do I gain by catching a specific exception?
If the point of catching an exception is to report it to the user,
then catching System.Exceptio n is completely appropriate.

If the point of catching an exception is to handle it, you should
be more specific.

Here's an example. You call a third-party subroutine that reads all
of the transactions for a given date and calculates the average.
Unfortunately that routine does not properly handle dates where no
transactions were processed; it gets a "division by 0" error. You
can still call the subroutine, but then you trap the divide-by-0
error and handle it by setting the average transaction amount to 0.
Is there any "easy" way to figure out the possible exceptions that
could be thrown by a given block of code?
Ideally, read the documentation that came with that block of code.
Otherwise, the only way I'm aware of is to test the heck out of it...
and then still trap System.Exceptio n so that you can nicely report
errors you aren't prepared to handle directly.
Pretty much any block of code that interacts w/ the database and
databinds some information could throw a who slew of possible
exceptions. Does anyone really list out every exception type that
could be thrown in this sitution, as FxCop is saying I should?

If the response is just to report "an exception occurred," you don't
want to get more specific.

My $0.02

[cmay]

Ok sounds like you and I am pretty much on the same page.

I DO have instances where I know that specific exceptions can occurr,
and I trap those specifically and deal with them.

But there are lots of times when I throw in a try / catch for blocks of
code when I am not sure how they will break, if ever, or if I don't
really all that much if they do break, just so long as they don't crash
the rest of the application.

The more I was reading into it, it looks like FxCop is trying to treat
my code as if I am going to deliver it to a 3rd party who is going to
need deatiled exceptions from me. Instead, I am the component
developer and the component consumer, so when I get an exception, I
don't need the component to throw detailed exceptions so much, because
I am reporting those exceptions and I can go in and fix the components,
or add more detailed error trapping when needed.

[carion1]

Generally you can find the specific exceptions a particular object throws in
the same name space the object is located.

"cmay" wrote:

Ok sounds like you and I am pretty much on the same page.

I DO have instances where I know that specific exceptions can occurr,
and I trap those specifically and deal with them.

But there are lots of times when I throw in a try / catch for blocks of
code when I am not sure how they will break, if ever, or if I don't
really all that much if they do break, just so long as they don't crash
the rest of the application.

The more I was reading into it, it looks like FxCop is trying to treat
my code as if I am going to deliver it to a 3rd party who is going to
need deatiled exceptions from me. Instead, I am the component
developer and the component consumer, so when I get an exception, I
don't need the component to throw detailed exceptions so much, because
I am reporting those exceptions and I can go in and fix the components,
or add more detailed error trapping when needed.

[cmay]

Ok sounds like you and I am pretty much on the same page.

I DO have instances where I know that specific exceptions can occurr,
and I trap those specifically and deal with them.

But there are lots of times when I throw in a try / catch for blocks of
code when I am not sure how they will break, if ever, or if I don't
really all that much if they do break, just so long as they don't crash
the rest of the application.

The more I was reading into it, it looks like FxCop is trying to treat
my code as if I am going to deliver it to a 3rd party who is going to
need deatiled exceptions from me. Instead, I am the component
developer and the component consumer, so when I get an exception, I
don't need the component to throw detailed exceptions so much, because
I am reporting those exceptions and I can go in and fix the components,
or add more detailed error trapping when needed.

[Joshua Flanagan]

If you are just reporting the exception, you will only want to catch
Exception at the highest level in your program. In that case, your
"components " should never catch it. It is assumed that your components
will be used by an application (which you also create). The benefit of
structure exception handling is that the exceptions will bubble up, so
that you only have to deal with them when you need to. If your
components do not know how to recover from an error, don't have them
catch exceptions at all. Leave it up to the "top" level application
(the closes to the user) to catch all exceptions and log/report them.

Joshua Flanagan
http://flimflan.com/blog

cmay wrote:

Ok sounds like you and I am pretty much on the same page.

I DO have instances where I know that specific exceptions can occurr,
and I trap those specifically and deal with them.

But there are lots of times when I throw in a try / catch for blocks of
code when I am not sure how they will break, if ever, or if I don't
really all that much if they do break, just so long as they don't crash
the rest of the application.

The more I was reading into it, it looks like FxCop is trying to treat
my code as if I am going to deliver it to a 3rd party who is going to
need deatiled exceptions from me. Instead, I am the component
developer and the component consumer, so when I get an exception, I
don't need the component to throw detailed exceptions so much, because
I am reporting those exceptions and I can go in and fix the components,
or add more detailed error trapping when needed.

[carion1]

Generally you can find the specific exceptions a particular object throws in
the same name space the object is located.

"cmay" wrote:

Ok sounds like you and I am pretty much on the same page.

I DO have instances where I know that specific exceptions can occurr,
and I trap those specifically and deal with them.

But there are lots of times when I throw in a try / catch for blocks of
code when I am not sure how they will break, if ever, or if I don't
really all that much if they do break, just so long as they don't crash
the rest of the application.

The more I was reading into it, it looks like FxCop is trying to treat
my code as if I am going to deliver it to a 3rd party who is going to
need deatiled exceptions from me. Instead, I am the component
developer and the component consumer, so when I get an exception, I
don't need the component to throw detailed exceptions so much, because
I am reporting those exceptions and I can go in and fix the components,
or add more detailed error trapping when needed.

[Joshua Flanagan]

If you are just reporting the exception, you will only want to catch
Exception at the highest level in your program. In that case, your
"components " should never catch it. It is assumed that your components
will be used by an application (which you also create). The benefit of
structure exception handling is that the exceptions will bubble up, so
that you only have to deal with them when you need to. If your
components do not know how to recover from an error, don't have them
catch exceptions at all. Leave it up to the "top" level application
(the closes to the user) to catch all exceptions and log/report them.

Joshua Flanagan
http://flimflan.com/blog

cmay wrote:

Ok sounds like you and I am pretty much on the same page.

I DO have instances where I know that specific exceptions can occurr,
and I trap those specifically and deal with them.

But there are lots of times when I throw in a try / catch for blocks of
code when I am not sure how they will break, if ever, or if I don't
really all that much if they do break, just so long as they don't crash
the rest of the application.

The more I was reading into it, it looks like FxCop is trying to treat
my code as if I am going to deliver it to a 3rd party who is going to
need deatiled exceptions from me. Instead, I am the component
developer and the component consumer, so when I get an exception, I
don't need the component to throw detailed exceptions so much, because
I am reporting those exceptions and I can go in and fix the components,
or add more detailed error trapping when needed.