try catch overhead.

[Gobinath]

Hi,

Is there any overhead attached with the try catch block? In C# everything is
an exception. So is it OK to have a try catch block for each function ??? or
is there any other way. What is the correct /efficient programming
practise??
Is there any other article available on the same?

Thanks for your time.

Regards,
Gobi.

[KWienhold]

On 6 Dez., 07:28, "Gobinath" <[e-mail]:

Hi,

Is there any overhead attached with the try catch block? In C# everything is
an exception. So is it OK to have a try catch block for each function ??? or
is there any other way. What is the correct /efficient programming
practise??
Is there any other article available on the same?

Thanks for your time.

Regards,
Gobi.

As long as there is no actual exception, the overhead is very small.
However, wrapping every single function into a try/catch block would
be somewhat unorthodox. Normally you let exceptions "bubble up" to a
global error handler on the top level and let that handle the error-
logging and display error information.
The obvious exception from this is when you anticipate a certain
exception and are able to recover from it, then you would wrap the
smallest possible piece of code in the try catch and only catch the
exceptions that you know you can recover from.
If you want more information on exceptions you should check out Jon
Skeet's homepage, he has a great collection of really useful articles
on many c# topics:
http://www.yoda.arachsys.com/csharp/exceptions2.html

hth,
Kevin Wienhold

[Wingot]

From: KWienhold [mailto:he******@trashmail.net]

Posted At: Thursday, 6 December 2007 3:47 PM
Posted To: microsoft.public.dotnet.languages.csharp
Conversation: try catch overhead.
Subject: Re: try catch overhead.

*snip*

As long as there is no actual exception, the overhead is very small.
However, wrapping every single function into a try/catch block would
be somewhat unorthodox. Normally you let exceptions "bubble up" to a
global error handler on the top level and let that handle the error-
logging and display error information.

*snip*

Hey KWien,

You mentioned error-logging be the global error handler. All I had
observed so far was the visible dialogue that comes up and "annoys" the
customer, who then proceeds to close it before calling to say something
was wrong.

Where would I find the error-log information? Event Viewer? A local
file? Within the Windows directory somewhere?

This would be very beneficial to know for debugging at the clients site
once they have closed the Exception screen and can't reproduce the
error.

Regards,
Wingot

[Jeff Louie]

Gobinath... Well, not _everything_ is an exception as C# does support
the Try,
out pattern as in Double.TryParse :)

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Peter Duniho]

On Wed, 05 Dec 2007 23:02:51 -0800, Wingot <wi****@newsgroup.nospamwrote:

Hey KWien,

You mentioned error-logging be the global error handler. All I had
observed so far was the visible dialogue that comes up and "annoys" the
customer, who then proceeds to close it before calling to say something
was wrong.

Where would I find the error-log information? Event Viewer? A local
file? Within the Windows directory somewhere?

I believe Kevin is referring to whatever custom error logging an
application might provide. His point is that you would only handle an
exception at a point in the code where you can do something useful about
it. If that "something" includes logging the exception, it would be
wherever the application designer decided to put it. The event log would
be a natural location, but it could be a local file or even transmitted to
a server somewhere.

For some exceptions, this handling may well be near the top level of your
code and it may be that the only useful thing to do is present the error
to the user (for example, by displaying an informational message, along
with the Exception.Message property value, in a MessageBox.Show()
statement), and/or logging the error somewhere as the developer sees fit,
and then just continuing to allow the user to use the application normally.

For other exceptions, it might be there's a sensible way to handle the
error at a deeper level in the code. For example, some sort of data entry
or i/o where the input data is invalid but some default can be provided
instead in the event of an exception. Again, the user may or may not be
alerted, the exception may or may not be logged, but any of that would be
up to the person writing the code.

As far as I know, there is no automated exception logging facility that
handles this sort of thing. It would be something implemented by the
developer of the program.

Pete

[eps]

Peter Duniho wrote:

As far as I know, there is no automated exception logging facility that
handles this sort of thing. It would be something implemented by the
developer of the program.

Pete

As you say there are lots of ways of doing this, I recently saw the
following on a code snippets site :

// Put this at the top
using System.IO;
//

public static void Log(string Message)
{
File.AppendAllText(HttpContext.Current.Server.MapP ath("~") +
"/log.txt", DateTime.Now.ToShortDateString() + " " +
DateTime.Now.ToShortTimeString() + ": " + Message + Environment.NewLine);
}
It impressed me due to the fact that its basically just one line (ok the
example above is meant for asp) I have used this in a c# class
library like so...

catch (Exception e)
{
File.AppendAllText(@"c:\log.txt", e.Message);
}
for a production system you may want to do a bit more but the above is
great for capturing exceptions whilst developing without crashing the app.

The code was taken from http://snippets.dzone.com/posts/show/4334

--
Eps

[KWienhold]

On 6 Dez., 08:02, "Wingot" <[e-mail]:

From: KWienhold [mailto:[e-mail]]
Posted At: Thursday, 6 December 2007 3:47 PM
Posted To: microsoft.public.dotnet.languages.csharp
Conversation: try catch overhead.
Subject: Re: try catch overhead.

*snip*

As long as there is no actual exception, the overhead is very small.
However, wrapping every single function into a try/catch block would
be somewhat unorthodox. Normally you let exceptions "bubble up" to a
global error handler on the top level and let that handle the error-
logging and display error information.

*snip*

Hey KWien,

You mentioned error-logging be the global error handler. All I had
observed so far was the visible dialogue that comes up and "annoys" the
customer, who then proceeds to close it before calling to say something
was wrong.

Where would I find the error-log information? Event Viewer? A local
file? Within the Windows directory somewhere?

This would be very beneficial to know for debugging at the clients site
once they have closed the Exception screen and can't reproduce the
error.

Regards,
Wingot

As Peter already mentioned, logging is normally implemented by the
developer, so it could be stored in many different locations.
Unfortunately many applications actually don't log their errors, but I
figured we were talking about applications that we wrote ourselves, so
its totally up to you.
Logging can be extremely useful for debugging purposes, as you pointed
out, since users are prone to just clicking "OK".
Another benefit is that you don't actually have to display the stack-
trace to the user (like MessageBox.Show("{0}", ex) would do), but you
can just dump it into a file and still have it available.
You may not think something like that is important, but after
explaining to a rather important customer what the method
"SpeedyGonzales.GoGoGo()" was (yeah, I have some great colleagues), I
really appreciate it ;)

On a sidenote, if you want to implement global error handling for
logging purposes you may want to take a look at the

AppDomain.CurrentDomain.UnhandledException
System.Windows.Forms.Application.ThreadException

events.

Kevin Wienhold

[Cor Ligthert[MVP]]

Gobinath,

As there are *To much* Try and Catch blocks used in a class, then it is for
me a sign that it is done by a beginner who did not understand why something
did not work, and fixed that with a Try and Catch to set some mostly wrong
values as result.

Just my idea about this.

Cor

[Gobinath]

Thanks a lot for all your response.. I think I have a better feeling for it
now..

Thanks a lot for your time.

Regards,
Gobi.
"Cor Ligthert[MVP]" <no************@planet.nlwrote in message
news:1B**********************************@microsof t.com...

Gobinath,

As there are *To much* Try and Catch blocks used in a class, then it is
for me a sign that it is done by a beginner who did not understand why
something did not work, and fixed that with a Try and Catch to set some
mostly wrong values as result.

Just my idea about this.

Cor

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

KWienhold wrote:

As long as there is no actual exception, the overhead is very small.
However, wrapping every single function into a try/catch block would
be somewhat unorthodox. Normally you let exceptions "bubble up" to a
global error handler on the top level and let that handle the error-
logging and display error information.

I don't agree with that for a large application.

I a large real world app then log+display+exit is likely not
good enough.

And in a multi layered component based world then the top level
is very unlikely to be able to do anything, because what has to be
done in case of an exception is also encapsulated somewhere.

Arne

[Jon Skeet [C# MVP]]

Arne Vajhøj <ar**@vajhoej.dkwrote:

KWienhold wrote:

As long as there is no actual exception, the overhead is very small.
However, wrapping every single function into a try/catch block would
be somewhat unorthodox. Normally you let exceptions "bubble up" to a
global error handler on the top level and let that handle the error-
logging and display error information.

I don't agree with that for a large application.

I a large real world app then log+display+exit is likely not
good enough.
And in a multi layered component based world then the top level
is very unlikely to be able to do anything, because what has to be
done in case of an exception is also encapsulated somewhere.

In a large application, you'd typically have each largish component or
perhaps each layer being responsible for dealing with exceptions.
However, you certainly *shouldn't* say "It's a large app, therefore
every single method should have its own try/catch block."

There should still be relatively few try/catch blocks even in a large
app, IMO.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Jon Skeet [C# MVP] wrote:

Arne Vajhøj <ar**@vajhoej.dkwrote:

>KWienhold wrote:

>>As long as there is no actual exception, the overhead is very small.
However, wrapping every single function into a try/catch block would
be somewhat unorthodox. Normally you let exceptions "bubble up" to a
global error handler on the top level and let that handle the error-
logging and display error information.

I don't agree with that for a large application.

I a large real world app then log+display+exit is likely not
good enough.
And in a multi layered component based world then the top level
is very unlikely to be able to do anything, because what has to be
done in case of an exception is also encapsulated somewhere.

In a large application, you'd typically have each largish component or
perhaps each layer being responsible for dealing with exceptions.
However, you certainly *shouldn't* say "It's a large app, therefore
every single method should have its own try/catch block."

There should still be relatively few try/catch blocks even in a large
app, IMO.

I don't think I have said otherwise.

I just object to the "global".

Arne

[Jon Skeet [C# MVP]]

On Dec 8, 10:08 pm, Arne Vajhøj <[e-mail]:

There should still be relatively few try/catch blocks even in a large
app, IMO.

I don't think I have said otherwise.

I just object to the "global".

It would have been helpful to have specified exactly which part you
didn't agree with then, rather than just quoting the whole response
and saying "I don't agree with that for a large application." It looks
like you disagree with the whole response rather than just one or two
words.

Jon

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Jon Skeet [C# MVP] wrote:

On Dec 8, 10:08 pm, Arne Vajhøj <[e-mail]:

>>There should still be relatively few try/catch blocks even in a large
app, IMO.

I don't think I have said otherwise.

I just object to the "global".

It would have been helpful to have specified exactly which part you
didn't agree with then, rather than just quoting the whole response
and saying "I don't agree with that for a large application." It looks
like you disagree with the whole response rather than just one or two
words.

I quoted:

# As long as there is no actual exception, the overhead is very small.
# However, wrapping every single function into a try/catch block would
# be somewhat unorthodox. Normally you let exceptions "bubble up" to a
# global error handler on the top level and let that handle the error-
# logging and display error information.

I could have omitted the first two and a half line or put in a
"so far I agree".

Instead I have people the opportunity to deduce that from
the argumentation what more specifically I disagreed with.

That strategy did not work very well.

I now understand that people can read:

#I a large real world app then log+display+exit is likely not
#good enough.
#
#And in a multi layered component based world then the top level
#is very unlikely to be able to do anything, because what has to be
#done in case of an exception is also encapsulated somewhere.

As an argument for a try catch in every method.

Arne