Using Try / Catch - Performance and best-practices

  • Thread starter Thread starter Daniel Portal
  • Start date Start date
D

Daniel Portal

Hi there,

I'm in 3-tier project and I'm thinking about having Try / Catch
statements in each method, just in case you know!
If the case is that I don't have a special treatment for the error in
some method I would Cath the error and Re-Throw it!

The question is: what are the issues of this approach? Would I have
performance problems cus of my catches? What does MS recommends in such a
situation??

Thanks a lot


Daniel Portal
 
Daniel,

You shouldn't do what you are doing. Basically, you should try and
catch only the exceptions you are expecting to get (and even then, if there
is another way to test for that condition, you should do so).

Otherwise, yes, you are going to place a huge strain on your system.

Hope this helps.
 
Some exceptions should be thrown to the caller. Business classes, for
example, should handle those exceptions they can handle gracefully, and pass
them up (by throwing) to the caller, so that the caller can handle it.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.
 
Unless I am missing some business specific purpose, you wouldnt gain
anything from doing a try/catch in every statement. Depending on your
scenario, you might not kill your speed -- but it certainly is a lot of
code that you probably wouldnt get any benefit for (and not to mention a
lot of additional testing because of the increased cyclomatic complexity)

In the past VB developers (not .NET) had on errors in every method
because that was the easiest way to build up a stack trace for tracking
down errors .... but with the StackTrace property of Exception that is
no longer necessary.
 
If it's not asking too much, is that possible to provide some official
article or reference that un-recommend this practice, or explains why not to
do it?

Thx

Nicholas Paldino said:
Daniel,

You shouldn't do what you are doing. Basically, you should try and
catch only the exceptions you are expecting to get (and even then, if
there is another way to test for that condition, you should do so).

Otherwise, yes, you are going to place a huge strain on your system.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Daniel Portal said:
Hi there,

I'm in 3-tier project and I'm thinking about having Try / Catch
statements in each method, just in case you know!
If the case is that I don't have a special treatment for the error in
some method I would Cath the error and Re-Throw it!

The question is: what are the issues of this approach? Would I have
performance problems cus of my catches? What does MS recommends in such a
situation??

Thanks a lot


Daniel Portal
Click to expand...
Click to expand...
 
Here you go, Daniel:

http://msdn.microsoft.com/library/d...e/html/cpconexceptionhandlingfundamentals.asp

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Complex things are made up of
Lots of simple things.

Daniel Portal said:
If it's not asking too much, is that possible to provide some official
article or reference that un-recommend this practice, or explains why not
to
do it?

Thx

Nicholas Paldino said:
Daniel,

You shouldn't do what you are doing. Basically, you should try and
catch only the exceptions you are expecting to get (and even then, if
there is another way to test for that condition, you should do so).

Otherwise, yes, you are going to place a huge strain on your system.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Daniel Portal said:
Hi there,

I'm in 3-tier project and I'm thinking about having Try / Catch
statements in each method, just in case you know!
If the case is that I don't have a special treatment for the error in
some method I would Cath the error and Re-Throw it!

The question is: what are the issues of this approach? Would I have
performance problems cus of my catches? What does MS recommends in such
a situation??

Thanks a lot


Daniel Portal
Click to expand...
Click to expand...
Click to expand...
 
Daniel Portal said:
If it's not asking too much, is that possible to provide some official
article or reference that un-recommend this practice, or explains why not to
do it?
Click to expand...

Your code becomes unreadable - you've got a much lower signal-to-noise
ratio in your code, because of the extra try/catch in each method,
whether it's required or not.

The performance issue is pretty much irrelevant here, IMO.
 
The "why not" is fairly straightforward: you gain nothing by catching
an exception that your application can't deal with at that point. If
you search this newsgroup for "try catch exception" or something like
that you'll find lots of threads on best practices. For example, here
are some recent conversations on the topic in which I was involved:

http://groups.google.com/group/micr..._frm/thread/c1d30d22b57bc6e7/204ccb521b5e15e8

http://groups.google.com/group/micr...e_frm/thread/150b7282069c75a/523571a29979c948

In a nutshell, catch an exception if:

1. The method catching the exception can deal with that specific
condition and continue working.
2. The exception type would be meaningless to your caller, and you want
to "wrap" the exception in a more meaningful exception.
3. You want to log additional information about your local state before
re-throwing the exception. (Either by logging the additional
information or by adding it to a "wrapper" exception.)
4. You want to note the exception and deal with it later.

and a couple of other reasons I can't remember right now. Otherwise,
what have you gained? You caught something you can't deal with, and at
best you just re-throw it. At worst you swallow an important exception.

There are top-level exception handling routines that you can hook into
the handle at the top level of your application all of those exceptions
that had no solution farther down your call stack. Of course, by that
time your application is going down anyway, but that's generally how
you handle exceptions with no remedy: allow them to bubble to the top
of the call stack, catch them in a global handler, log them, and then
allow the app to go down.
 
Back
Top