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]

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:[email protected]]

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

 

[Peter Duniho]

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]

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.MapPath("~") +
"/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

 

[Gobinath]

Thank you all for your response.

e.g. In a SortedList<T,T>, if we try to add a key which is already existing
then it's an exception.
To avoid this we can make a lookup before we add.

Say in a senario where such an occurance is very rare and it's perfectly OK
to ignore the new entry if it exist already.

If this statement is executed often then I don't want to do a lookup
everytime before adding because it'll be an overhead.
else
I have to put try.. catch for the Add statement not the entire function..

There are MANY such examples.. so how do we handle such scenario.. we can
put try.. catch for each such statements, it's not only an overhead but also
very cumbersome..


Thanks all for your time.

Regards,
Gobi.

 

[Jon Skeet [C# MVP]]

Thank you all for your response.

e.g. In a SortedList<T,T>, if we try to add a key which is already existing
then it's an exception.
To avoid this we can make a lookup before we add.

Say in a senario where such an occurance is very rare and it's perfectly OK
to ignore the new entry if it exist already.

If this statement is executed often then I don't want to do a lookup
everytime before adding because it'll be an overhead.

Until you have any indication that this is actually a bottleneck, I
wouldn't worry - but measure. Looking up an entry is incredibly quick.
It's very unlikely to be a bottleneck/.

else
I have to put try.. catch for the Add statement not the entire function..

There are MANY such examples.. so how do we handle such scenario.. we can
put try.. catch for each such statements, it's not only an overhead but also
very cumbersome..

You shouldn't use try/catch for things like that - it's an abuse of
exceptions, IMO. They should be used to catch unexpected situations -
or at least ones that can't be reliably tested for first. If you
shouldn't be adding an entry if one already exists, you should do the
check first.

Aside from anything else, the explicit code will be *much* clearer in
terms of intention than the try/catch code.

Of course, in cases where a "try this" option is available, like
TryParse, TryGetValue etc, that's the most appropriate solution.

 

[KWienhold]

From: KWienhold [mailto:[email protected]]
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

 

[Jeff Louie]

Gobinath... If it is possible for the caller to completely validate the
pre-
condition, then one would argue that caller should just validate the
pre-
condition and not trap for the specific pre-condition exception; This is
the
tester-doer idiom.

As John says, one should not worry about the overhead in a Tester-Doer
idiom
unless one encounters a bottleneck. If you find a bottleneck using the
Tester-
Doer idiom then consider using the try,out idiom.

Sometimes, especially in multithreaded code, there may no way to
completely
validate a precondition.

http://blogs.msdn.com/kcwalina/archive/2005/03/16/396787.aspx
http://www.geocities.com/jeff_louie/OOP/oop14.htm

Regards,
Jeff

 

[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.

 

[Arne Vajhøj]

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

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.

 

[Arne Vajhøj]

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

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

 

[Arne Vajhøj]

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