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" <gobinat...@coo lgoose.comwrote :

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.publi c.dotnet.langua ges.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****@newsgro up.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.Messa ge 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.AppendAllT ext(HttpContext .Current.Server .MapPath("~") +
"/log.txt", DateTime.Now.To ShortDateString () + " " +
DateTime.Now.To ShortTimeString () + ": " + Message + Environment.New Line);
}
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.AppendAllT ext(@"c:\log.tx t", 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" <win...@newsgro up.nospamwrote:

From: KWienhold [mailto:hedov... @trashmail.net]
Posted At: Thursday, 6 December 2007 3:47 PM
Posted To: microsoft.publi c.dotnet.langua ges.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.Curre ntDomain.Unhand ledException
System.Windows. Forms.Applicati on.ThreadExcept ion

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******** *************** ***********@mic rosoft.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+exi t 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