Using Try / Catch - Performance and best-practices

[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

[Nicholas Paldino [.NET/C# MVP]]

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]
- mv*@spam.guard. caspershouse.co m

"Daniel Portal" <it********@bol .com.br> wrote in message
news:er******** ******@TK2MSFTN GP12.phx.gbl...

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

[Kevin Spencer]

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.

"Daniel Portal" <it********@bol .com.br> wrote in message
news:er******** ******@TK2MSFTN GP12.phx.gbl...

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

[John Murray]

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.
Daniel Portal wrote:

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 Portal]

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 [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c om> wrote in
message news:%2******** **********@TK2M SFTNGP15.phx.gb l...

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]
- mv*@spam.guard. caspershouse.co m

"Daniel Portal" <it********@bol .com.br> wrote in message
news:er******** ******@TK2MSFTN GP12.phx.gbl...

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

[Kevin Spencer]

Here you go, Daniel:

http://msdn.microsoft.com/library/de...ndamentals.asp

--
HTH,

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

"Daniel Portal" <it********@bol .com.br> wrote in message
news:O$******** ******@TK2MSFTN GP09.phx.gbl...

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 [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c om> wrote
in message news:%2******** **********@TK2M SFTNGP15.phx.gb l...

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]
- mv*@spam.guard. caspershouse.co m

"Daniel Portal" <it********@bol .com.br> wrote in message
news:er******** ******@TK2MSFTN GP12.phx.gbl...

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

[Jon Skeet [C# MVP]]

Daniel Portal <it********@bol .com.br> wrote:

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?

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Bruce Wood]

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/micro...4ccb521b5e15e8

http://groups.google.com/group/micro...3571a29979c948

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.

[Daniel Portal]

Thanks Bruce...

If anyone has more interest in this subject, I found this guy who might be
quite useful for everyone:

http://www.microsoft.com/downloads/d...displaylang=en

And hanks everyone who invested time replying this... kinda dumb question,
but it had to be asked!

"Bruce Wood" <br*******@cana da.com> wrote in message
news:11******** *************@g 43g2000cwa.goog legroups.com...

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/micro...4ccb521b5e15e8

http://groups.google.com/group/micro...3571a29979c948

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.