Overuse of try catch?

[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

[Mike Labosh]

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

[Herfried K. Wagner [MVP]]

* "STom" <st***********@hotmail.com> scripsit:

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?

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.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[William Ryan]

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
"STom" <st***********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

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

[Tom Spink]

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" <st***********@hotmail.com> wrote in message
news:#L**************@TK2MSFTNGP09.phx.gbl...

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

[Joe \Nuke Me Xemu\ Foster]

"STom" <st***********@hotmail.com> wrote in message <news:#L**************@TK2MSFTNGP09.phx.gbl>...

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?

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.

--
Joe Foster <mailto:jlfoster%40znet.com> Space Cooties! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[William Ryan]

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
"Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
news:OV**************@TK2MSFTNGP10.phx.gbl...

"STom" <st***********@hotmail.com> wrote in message <news:#L**************@TK2MSFTNGP09.phx.gbl>...

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

--
Joe Foster <mailto:jlfoster%40znet.com> Space Cooties!

<http://www.xenu.net/> WARNING: I cannot be held responsible for the above They're coming to because my cats have apparently learned to type. take me away, ha ha!

[Joe \Nuke Me Xemu\ Foster]

"William Ryan" <do********@nospam.comcast.net> wrote in message <news:eS**************@TK2MSFTNGP09.phx.gbl>...

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

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"?

--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Rob Teixeira [MVP]]

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]

"William Ryan" <do********@nospam.comcast.net> wrote in message
news:eS**************@TK2MSFTNGP09.phx.gbl...

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
"Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
news:OV**************@TK2MSFTNGP10.phx.gbl...

"STom" <st***********@hotmail.com> wrote in message

<news:#L**************@TK2MSFTNGP09.phx.gbl>...

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?

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.

--
Joe Foster <mailto:jlfoster%40znet.com> Space Cooties!

<http://www.xenu.net/>

WARNING: I cannot be held responsible for the above They're

coming to

because my cats have apparently learned to type. take me away,

ha ha!

[William Ryan]

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" <jo*@bftsi0.UUCP> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

"William Ryan" <do********@nospam.comcast.net> wrote in message <news:eS**************@TK2MSFTNGP09.phx.gbl>...

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
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"?

--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/> WARNING: I cannot be held responsible for the above They're coming to because my cats have apparently learned to type. take me away, ha ha!

[Joe \Nuke Me Xemu\ Foster]

"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message <news:#$**************@TK2MSFTNGP09.phx.gbl>...

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

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.

--
Joe Foster <mailto:jlfoster%40znet.com> L. Ron Dullard <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Tom Shelton]

On 2003-12-24, STom <st***********@hotmail.com> wrote:

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

http://msdn.microsoft.com/library/de...etperftips.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.

--
Tom Shelton
MVP [Visual Basic]

[Tom Shelton]

On 2003-12-25, William Ryan <do********@nospam.comcast.net> wrote:

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

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

--
Tom Shelton
MVP [Visual Basic]

[Joe \Nuke Me Xemu\ Foster]

"William Ryan" <do********@nospam.comcast.net> wrote in message <news:eP**************@TK2MSFTNGP11.phx.gbl>...

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

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/computin...des/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.

--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Joe \Nuke Me Xemu\ Foster]

"Tom Shelton" <to*@mtogden.com> wrote in message <news:ur**************@TK2MSFTNGP11.phx.gbl>...

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

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.

--
Joe Foster <mailto:jlfoster%40znet.com> L. Ron Dullard <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Cor]

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

[STom]

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
"Tom Shelton" <to*@mtogden.com> wrote in message
news:uv**************@TK2MSFTNGP11.phx.gbl...

On 2003-12-24, STom <st***********@hotmail.com> wrote:

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

http://msdn.microsoft.com/library/de...etperftips.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.

--
Tom Shelton
MVP [Visual Basic]

[William Ryan]

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" <jo*@bftsi0.UUCP> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

"William Ryan" <do********@nospam.comcast.net> wrote in message <news:eS**************@TK2MSFTNGP09.phx.gbl>...

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
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"?

--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/> WARNING: I cannot be held responsible for the above They're coming to because my cats have apparently learned to type. take me away, ha ha!

[Rob Teixeira [MVP]]

"Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
news:ey**************@TK2MSFTNGP12.phx.gbl...

"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message <news:#$**************@TK2MSFTNGP09.phx.gbl>...
Cite?
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.
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.
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?
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?
Where is this tangent leading?
If your own components have reference bugs, that's your
own fault, not somehow Visual Basic's.

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]

[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]
"Tom Shelton" <to*@mtogden.com> wrote in message
news:uv**************@TK2MSFTNGP11.phx.gbl...

On 2003-12-24, STom <st***********@hotmail.com> wrote:

http://msdn.microsoft.com/library/de...etperftips.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.

--
Tom Shelton
MVP [Visual Basic]

[Joe \Nuke Me Xemu\ Foster]

"William Ryan" <do********@nospam.comcast.net> wrote in message <news:OU**************@TK2MSFTNGP10.phx.gbl>...

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!

Sure, moron, given that "the Linux crowd" still primarily uses C,
and thus neither RAII nor the Rule of Three will apply to them.
However, you made the ludicrous claim that you are a "seasoned C++
programmer", when in fact you appear to be unfamiliar with idioms
that have been standard practice in C++ for nearly ten years. Are
you even aware that C and C++ are different languages at all?

--
Joe Foster <mailto:jlfoster%40znet.com> L. Ron Dullard <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Joe \Nuke Me Xemu\ Foster]

"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message <news:e4**************@tk2msftngp13.phx.gbl>...

"Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
news:ey**************@TK2MSFTNGP12.phx.gbl...

"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message

<news:#$**************@TK2MSFTNGP09.phx.gbl>...

Cite?

Feel free to search the various VB groups for Joe Foster and Matt Curland.
You know exactly what I'm talking about.

Put down the crack pipe and back away slowly. My complaints about
Matthew "Access to Source" Curland have primarily to do with his
rather fragile "solutions", such as his "lightweight COM objects",
not with the concept of value types with methods and destructors.
I've been wishing for Type_Initialize and Type_Terminate in Visual
Basic for quite some time.

--
Joe Foster <mailto:jlfoster%40znet.com> Auditine Addict <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Jay B. Harlow [MVP - Outlook]]

STom,
In addition to Tom's article:

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

Something like:

Public Sub Main()
AddHandler Application.ThreadException, AddressOf OnThreadException
Application.Run(New MainForm)
End Sub

Private Sub OnThreadException(sender As Object, _
ByVal e As System.Threading.ThreadExceptionEventArgs)
Try
' Log the exception & possible show user the info...
Catch ex As Exception
' Don't want to end the app here! ;-)
End Try
End Sub

Using one (or more) of the above global handlers allows your application to
log the exception in the handler and allows your app to continue processing,
saving your from adding Try/Catch in each of your Form's event handlers for
example.

Hope this helps
Jay
"STom" <st***********@hotmail.com> wrote in message
news:O8**************@TK2MSFTNGP10.phx.gbl...

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
"Tom Shelton" <to*@mtogden.com> wrote in message
news:uv**************@TK2MSFTNGP11.phx.gbl...

On 2003-12-24, STom <st***********@hotmail.com> wrote:

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

http://msdn.microsoft.com/library/de...etperftips.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.

--
Tom Shelton
MVP [Visual Basic]