Overuse of try catch?

  • Thread starter Thread starter STom
  • Start date Start date
S

STom

I heard someone mention to me that the use of try catch exception handling
is very expensive (in relative terms of slowing an app down) if it is used
frequently. Of course they could not explain why.

Is this true? If so, why?

Thanks.

STom
 
* "STom said:
I heard someone mention to me that the use of try catch exception handling
is very expensive (in relative terms of slowing an app down) if it is used
frequently. Of course they could not explain why.

Is this true? If so, why?
Click to expand...

Have a look at the 'Exception' class. An 'Exception' stores a lot of
information about the exception, the exception will be thrown (this will
direct the control to other parts of the application) etc. Using, for
example, a Boolean value for indicating success/failure, will increase
performance rapidely, but you will have to do the "handling" yourself.
 
All of the performance tidbits I have heard about the new error handling are
complaining that Throwing exceptions waste time.

I imagine doing something like this doesn't hurt [much], but is indeed
rather unneccesary. If i += 1 fails, the machine has a bigger problem than
whether or not your code uses error handling:

Dim i As Integer

Try
i += 1
Catch e As Exception
MessageBox.Show("Bogus")
End Try

As with any toolbox, I try to keep in mind that that I should use the
correct tool for the job, and only when actually needed.

Try...Catch is neccesary around an ADO.NET SqlConnection.Open() and other
such things that have a higher probability of failing. You wouldn't want to
use Try...Catch around every single piece of code.

Just my two cents.
--
Peace & happy computing,

Mike Labosh, MCSD MCT
Owner, vbSensei.Com
"Escriba coda ergo sum." -- vbSensei
 
Yes, it is. Exceptions are costly and verifying them before hand is even
moreso. If you really want to know why, compile a project, and run it
through ILDASM.exe. Then, add a bunch of try catch blocks and see how much
more code is generated. You may not be familiar with IL, but it's pretty
clear. And the worst thing in the World that should be outlawed is On Error
Resume Next, that wraps every line in a try catch block. Think about it for
a second, if you never checked anything beforehand, from a file's existence
to the existence of a variable, couldn't you write a lot less code (and a
lot buggier?) Well, this is magnified by Try Catch becuase of the way it
executes (not an exact analogy, but close)

Anyway, here's the deal...Try catch shouldn't be used all over the place.
You should only use System.Exception at top level calls b/c Try Catch is
made to help you respond to specific exceptions, and you certainly aren't
writng a special handler at every block for a SystemOutOfMemoryException for
instance.

I guess the best way to analogize it is this. You need your car keys to get
home from the office if you are driving. Wouldn't it make more sense to
only check that you have your keys when you first leave for work, and then
when you are ready to leave? Vs. Checking for your keys every time you do
anything all day? Do you really need to check for your keys when you hit
the men's room? Or log onto a computer. Or call a client? No. It's still
important, but it has nothign to do with the task at hand. It won't stop
you from doing your job, but it will slow it down, and possibly so much so
that it would impede performance..

HTH,

Bill
 
Hi STom,

In addition to what others have said, I forbid you to look at unstructured
error handling. IMO it is old and bad practice... basically it's the .NET
equivalent of the On Error Resume Next malarkey.

It is much more costly than structured exception handling...
Try...Catch...Finally.

Also, put it in where it's critical... most things can be checked for "Is
Nothing" with a simple if statement, rather than waiting for an exception to
be thrown from some adjacent code.

--
HTH,
-- Tom Spink, Über Geek

Please respond to the newsgroup,
so all can benefit

" System.Reflection Master "

==== Converting to 2002 ====
Remove inline declarations
 
STom said:
I heard someone mention to me that the use of try catch exception handling
is very expensive (in relative terms of slowing an app down) if it is used
frequently. Of course they could not explain why.

Is this true? If so, why?
Click to expand...

It is overused because .NyET does not support deterministic finalization,
so Try/Catch/Finally or C#'s "using" statement are needed to kludge what
should be automatic. B#'s "Finally" and C#'s "using" statements, and
quite a bit of error handling code in general, could be disposed of if
value types could have finalizers. When a value type is allocated on the
stack as a local variable within a subroutine, pending finalizers could be
called automatically when the subroutine exits for any reason, including
stack unwinding due to an uncaught exception's being passed back to the
caller. True, the garbage collector would need to be able to put class
instances on the finalization queue when they have member variables of
value types having finalizers, even if the class doesn't have a finalizer
itself. The order in which value type finalizers are called within a
subroutine's local variables or a class instance's members should also be
defined and predictable.
 
Should be automatic? Are you kidding? I'm a seasoned C++ programmer and
love disposing of my own stuff...but no matter how careful you are...tell me
humans can preempt memory leaks. A Kluge? Hardly. When's the last time a
hacker pulled a buffer overflow on your GC based app?

Other than that, I don't take issue with what you said, but that's a big and
incorrect claim you made
 
William Ryan said:
Should be automatic? Are you kidding? I'm a seasoned C++ programmer and
love disposing of my own stuff...but no matter how careful you are...tell me
humans can preempt memory leaks. A Kluge? Hardly. When's the last time a
hacker pulled a buffer overflow on your GC based app?

Other than that, I don't take issue with what you said, but that's a big and
incorrect claim you made
Click to expand...

You cannot possibly be "a seasoned C++ programmer" if you "love disposing
of [your] own stuff" instead of using wrapper classes like a sane person.

URL:http://hackcraft.net/raii/

URL:http://www.research.att.com/~bs/bs_faq2.html#finally considered harmful

URL:http://www.research.att.com/~bs/3rd_safe0.html

When's the last time a hacker pulled a buffer overflow on your C++ based
app? Fairly recently, I would imagine. Are you even familiar with the
"Rule of Three"?
 
Don't worry Will, Joe has been running out of things to complain about for
years, and he's latched onto the Disposing thing for quite some time now.
Just ignore his ranting. He'll find a way to twist any topic to the
Disposing issue.
Last time I remember seeing his rant it went on for weeks. And ironically,
he was bashing Matt Curland's theory of setting automatic and deterministic
cleanup for value types with local scope at the time within the CLI/runtime.
First of all, .NET does support deterministic finalization. It's called the
Dispose method.
Furthermore, his statement that VB's Finally clause could be disposed of if
value types had finalizers is a far stretch. Value types make up a small
percentage of types, not to mention that most types encasing unmanaged
resources are reference types, and the Finally statement is used for running
code that requires execution regardless of whether an exception occurs or
not - not just cleanup code.

It's sad to ignore all the benefits of .NET just because you can't run
Class_Terminate-style code in a deterministic manner without explicitly
calling Dispose - a very small price to pay, mind you. Besides, how many
times have you seen people forget to set a non-local object reference to
nothing in old VB?

-Rob Teixeira [MVP]
 
Really? If your code doesn't handle dynamic memory allocation, than what
is your complaint? Am I missing something? Ummm, Ok, I'll play with you..
what does your brilliant 3:33t wrapper class do ? More importantly, how does
that invalidate any point I made?

So here, I'll play along.. Fill me in genius.... what language accomplishes
your objectives with no side effects? I'm on record here.... I don't think
you have a clue what you are talking about, actually, I'm certain of that.

And for the record...I never had my app hacked, professionally, I never
wrote anything alone. In this day and age, it'd be a fool's endeavor. But
I've worked with 3 top NASDAQ companies (I'll be glad to prove this, are you
willing to do so) who have had this happen...and that's part of what .NET
solved!

Why am I even arguing with you, you are a fake. Come up with a real
complaint about .NET, trust me, you'll get press coverage. But you
can't..........................Cheers Nobody


Bill


Joe "Nuke Me Xemu" Foster said:
"William Ryan" <[email protected]> wrote in message
Should be automatic? Are you kidding? I'm a seasoned C++ programmer and
love disposing of my own stuff...but no matter how careful you are...tell me
humans can preempt memory leaks. A Kluge? Hardly. When's the last time a
hacker pulled a buffer overflow on your GC based app?

Other than that, I don't take issue with what you said, but that's a big and
incorrect claim you made
Click to expand...

You cannot possibly be "a seasoned C++ programmer" if you "love disposing
of [your] own stuff" instead of using wrapper classes like a sane person.

URL:http://hackcraft.net/raii/

URL:http://www.research.att.com/~bs/bs_faq2.html#finally considered harmful

URL:http://www.research.att.com/~bs/3rd_safe0.html

When's the last time a hacker pulled a buffer overflow on your C++ based
app? Fairly recently, I would imagine. Are you even familiar with the
"Rule of Three"?
Click to expand...
 
Are you serious? I was actually ready to really defend my position until I
read the rest of your post.... I'll promise you, even the Linux crowd will
back me on this one.. I can't wait until your job moves to another country!
Joe "Nuke Me Xemu" Foster said:
"William Ryan" <[email protected]> wrote in message
Should be automatic? Are you kidding? I'm a seasoned C++ programmer and
love disposing of my own stuff...but no matter how careful you are...tell me
humans can preempt memory leaks. A Kluge? Hardly. When's the last time a
hacker pulled a buffer overflow on your GC based app?

Other than that, I don't take issue with what you said, but that's a big and
incorrect claim you made
Click to expand...

You cannot possibly be "a seasoned C++ programmer" if you "love disposing
of [your] own stuff" instead of using wrapper classes like a sane person.

URL:http://hackcraft.net/raii/

URL:http://www.research.att.com/~bs/bs_faq2.html#finally considered harmful

URL:http://www.research.att.com/~bs/3rd_safe0.html

When's the last time a hacker pulled a buffer overflow on your C++ based
app? Fairly recently, I would imagine. Are you even familiar with the
"Rule of Three"?
Click to expand...
 
Rob Teixeira said:
Don't worry Will, Joe has been running out of things to complain about for
years, and he's latched onto the Disposing thing for quite some time now.
Just ignore his ranting. He'll find a way to twist any topic to the
Disposing issue.
Last time I remember seeing his rant it went on for weeks. And ironically,
he was bashing Matt Curland's theory of setting automatic and deterministic
cleanup for value types with local scope at the time within the CLI/runtime.
Click to expand...

Cite? Anyway, even if value types were to be extended as I described,
migrating VB5/6 code to what Micro$haft laughably claims to be "Visual
Basic" these days would be ridiculous.
First of all, .NET does support deterministic finalization. It's called the
Dispose method.
Furthermore, his statement that VB's Finally clause could be disposed of if
value types had finalizers is a far stretch. Value types make up a small
percentage of types, not to mention that most types encasing unmanaged
resources are reference types, and the Finally statement is used for running
code that requires execution regardless of whether an exception occurs or
not - not just cleanup code.
Click to expand...

You seem unclear about the concepts of "cause" and "effect". "Most
types encasing unmanaged resources are reference types" precisely
because value types are currently not very useful for this purpose.
I'm sure their use would become more common if they were extended
in the way I described.
It's sad to ignore all the benefits of .NET just because you can't run
Class_Terminate-style code in a deterministic manner without explicitly
calling Dispose - a very small price to pay, mind you. Besides, how many
times have you seen people forget to set a non-local object reference to
nothing in old VB?
Click to expand...

What are you babbling about? Are you trying to claim deterministic
finalization is impossible in VB now? Or are you merely hallucinating
based on the old problems with .Close and .Quit endemic to Microsoft
components? If your own components have reference bugs, that's your
own fault, not somehow Visual Basic's.
 
I heard someone mention to me that the use of try catch exception handling
is very expensive (in relative terms of slowing an app down) if it is used
frequently. Of course they could not explain why.

Is this true? If so, why?

Thanks.

STom
Click to expand...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftips.asp

According to the above article:

======================================================================
"Throwing exceptions can be very expensive, so make sure that you don't
throw a lot of them. Use Perfmon to see how many exceptions your
application is throwing. It may surprise you to find that certain areas
of your application throw more exceptions than you expected. For better
granularity, you can also check the exception number programmatically by
using Performance Counters.

Finding and designing away exception-heavy code can result in a decent
perf win. Bear in mind that this has nothing to do with try/catch
blocks: you only incur the cost when the actual exception is thrown. You
can use as many try/catch blocks as you want. Using exceptions
gratuitously is where you lose performance. For example, you should stay
away from things like using exceptions for control flow."
======================================================================

So, as you can see there is virtually NO overhead for simply having a
try/catch in your code. The overhead is only incured if you actually
have to deal with an exception. It is a good idea to design code to
throw as few exceptions as possible.... A little defensive coding can
go a long way to make this happen.
 
Really? If your code doesn't handle dynamic memory allocation, than what
is your complaint? Am I missing something? Ummm, Ok, I'll play with you..
what does your brilliant 3:33t wrapper class do ? More importantly, how does
that invalidate any point I made?

So here, I'll play along.. Fill me in genius.... what language accomplishes
your objectives with no side effects? I'm on record here.... I don't think
you have a clue what you are talking about, actually, I'm certain of that.

And for the record...I never had my app hacked, professionally, I never
wrote anything alone. In this day and age, it'd be a fool's endeavor. But
I've worked with 3 top NASDAQ companies (I'll be glad to prove this, are you
willing to do so) who have had this happen...and that's part of what .NET
solved!

Why am I even arguing with you, you are a fake. Come up with a real
complaint about .NET, trust me, you'll get press coverage. But you
can't..........................Cheers Nobody


Bill
Click to expand...

Bill, your wasting your time. Joe is a one trick pony. All he ever
rants about is DF this and DF that. Joe is in love with Reference
counting. To him, it seems to be the be all-end all of resource
managment. It matters not that he has been shown numerous times that
there are as many issues with ref counting (cycles, performance,
etc.) as there are with GC...
 
William Ryan said:
Really? If your code doesn't handle dynamic memory allocation, than what
is your complaint? Am I missing something? Ummm, Ok, I'll play with you..
what does your brilliant 3:33t wrapper class do ? More importantly, how does
that invalidate any point I made?

So here, I'll play along.. Fill me in genius.... what language accomplishes
your objectives with no side effects? I'm on record here.... I don't think
you have a clue what you are talking about, actually, I'm certain of that.

And for the record...I never had my app hacked, professionally, I never
wrote anything alone. In this day and age, it'd be a fool's endeavor. But
I've worked with 3 top NASDAQ companies (I'll be glad to prove this, are you
willing to do so) who have had this happen...and that's part of what .NET
solved!

Why am I even arguing with you, you are a fake. Come up with a real
complaint about .NET, trust me, you'll get press coverage. But you
can't..........................Cheers Nobody
Click to expand...

I'd have to conclude that you are the fake here, despite your having
been deadwood at three top NASDAQ companies. Do you even know who
Bjarne Stroustrup is? Two of the links I posted point into his C++
FAQs. The third merely points to one of the best explanations of the
RAII principle I've yet found. I'll even post them again, so as to
prevent your blowing a gasket by having to search for them upthread:

URL:http://www.research.att.com/~bs/bs_faq2.html#finally considered harmful

URL:http://www.research.att.com/~bs/3rd_safe0.html

URL:http://hackcraft.net/raii/

As for the "Rule of Three", of which you're probably also unaware,
I will try to find something simple enough for you to comprehend:

URL:http://www.comp.lancs.ac.uk/computing/users/marash/SlidesCpp/slides/sld067.htm

Both the Rule of Three and RAII have been standard practice in C++
for about a decade. Your ignorance explains, but hardly excuses,
your delusion that .NET is absolutely any improvement whatsoever.
Value types with finalizers would merely make .NET somewhat less
painful.

For the record, my favorite programming language is VB 5.0 EE SP3.
 
Tom Shelton said:
Bill, your wasting your time. Joe is a one trick pony. All he ever
rants about is DF this and DF that. Joe is in love with Reference
counting. To him, it seems to be the be all-end all of resource
managment. It matters not that he has been shown numerous times that
there are as many issues with ref counting (cycles, performance,
etc.) as there are with GC...
Click to expand...

If I actually thought RC was "the be all-end all of resource management"
as you so persistently hallucinate, then why don't you explain away the
fact that the possible extension to value types I mentioned does *not*
include anything about reference counting, mmkay? Also, any performance
problems with RC in COM are due solely to Microslop's implementation of
RC, not with RC per se. Even in a multiprocessor scenario, incrementing
or decrementing a reference count is a matter of *one* CPU instruction.
I never did understand why IUnknown::AddRef exists at all, when AddRef's
address could simply be replaced with the address of the reference count
and IUnknown::Release with the actual destructor, so incrementing and
decrementing the reference count could be inlined. Oh well, too late now.
And as for cyclical references, wrapper classes come in handy there, too,
and unlike with .NyET's IDispose kludgery, encapsulation can be preserved.
 
Hi Stom,

If there is a function/methode/api whatever and you use try, catch end try
instead, you are in my eyes a fool, because therefore it is not.

Example
I saw here programs (in pseudo)
Try
read file
catch execption
message file does maybe not exist
end try

For that it is not made, you can check that before with a less performance
expensive "file.exist?

And when is after this
Try
read file
catch execption
message something strange happened with the file while reading
end try

Than it is in my eyes good use.

Just my thoughts.

Cor
 
Thanks Tom for pointing me to the article...and thanks to everyone else for
their thoughts/opinions...I did not intend to start a war though :-)

My thought behind try/catch is that if there is an exception, and the app is
going to halt anyway, how terribly important is it that it halts quickly?
For example, if the exception were thrown 8 levels deep and had to be
rethrown all the way back to the top, the app is going to probably appear to
hang for a short period of time before a message box or whatever displays
the error.

Thanks again.

STom
 
Joe "Nuke Me Xemu" Foster said:
"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message
Click to expand...
Cite?
Click to expand...

Feel free to search the various VB groups for Joe Foster and Matt Curland.
You know exactly what I'm talking about.
Anyway, even if value types were to be extended as I described,
migrating VB5/6 code to what Micro$haft laughably claims to be "Visual
Basic" these days would be ridiculous.
Click to expand...

Interesting. I and many others have been migrating code for years now. If it
was so ridiculous, don't you think we would all have quit by now?
By the way, your overuse of the cute little idioms like "Micro$haft" have
historically never helped your arguments. Why persist?
You seem unclear about the concepts of "cause" and "effect". "Most
types encasing unmanaged resources are reference types" precisely
because value types are currently not very useful for this purpose.
I'm sure their use would become more common if they were extended
in the way I described.
Click to expand...

Not quite. Value types and Reference types have very different behavious,
among them - value types cannot inherit base classes, and there are
limitations over implementing interfaces with them, as well as the
referencing differences due to boxing. Value types serve their purpose, but
they are not a replacement for the class structure. There are many good
reasons why there are far more reference types than value types, and it has
nothing to do with usefulness. Both types are used for a reason.
What are you babbling about? Are you trying to claim deterministic
finalization is impossible in VB now?
Click to expand...

Hardly. You missed my opening statement that VB.NET does indeed have
deterministic finalization - it's called the Dispose method.
Or are you merely hallucinating
based on the old problems with .Close and .Quit endemic to Microsoft
components?
Click to expand...

Where is this tangent leading?
If your own components have reference bugs, that's your
own fault, not somehow Visual Basic's.
Click to expand...

Exactly. The same still holds true. Thanks for making my point for me.

You know, I'd think you'd be over all the ranting by now. If you hate the
product so much, why are you still here after years?
Feel free to post when learn how to contribute something meaningful
(operative word being CONTRIBUTE, which last I heard, was not the same
RANT).

-Rob Teixeira [MVP]
 
Absolutely. The point of the various articles STom may have read is that you
don't want to THROW exceptions to control program flow - which inherintly
involves using Try .. Catch. By doing this, you are virtually garanteeing
that many exceptions will be thrown during the course of your program's
execution when in most cases, a simple boolean expression would have been
sufficient.
As Tom points out, the overhead itself is about creating and throwing the
exception, not necessarily in using Try .. Catch. By using Try .. Catch you
can actually save yourself a lot of code.

-Rob Teixeira [MVP]
 
Back
Top