Re: Exception handling?
"Goran" <goran.pusic@gmail.com> wrote in message
news:d5d4107e-3b75-4a3f-be81-45c2c0d916a2@d37g2000yqm.googlegroups.com...
Thing is also that .NET exceptions, like MFC (and VCL) ones, can
really be costly: they are on the heap, they are info-rich (e.g.
there's a CString inside) etc. But despite that, I still say, just
like you: there's no performance problems with exceptions; if there
is, programmer is doing something horribly wrong in 99% of cases ;-).
And absolutely, programmer does not know, by looking at any non-
trivial the code, where it's slow, too!
Hi Goran, well I understand your point. My favorite string class is
CString, and I use it by default. But I once had a situation on startup
where the profiler showed a lot of time in copying CString, so we replaced a
few lines of code to use lstrcpy() instead of CString, and that saved
significant time. So I understand your point that exceptions in general are
very usable, but it's only in certain situations where they cause a
noticeable problem.
And perhaps .NET exceptions are more costly than C++ ones, I don't know. (I
didn't use exceptions in C++, I only started using them because I had no
choice when I went to .NET.) I will say it is a common in .NET programming
to run in the debugger with first chance exceptions being enabled so you are
well aware of any exceptions being thrown. And when I eliminate those, the
program does seem to run a bit faster, but I don't know if that is my
imagination or not. It does seem avoiding unnecessary exceptions is
emphasized more in .NET, but I always thought that was because they are used
more in .NET. Also perhaps because it involves loading more assemblies to
deal with the exception, and loading assemblies is expensive.
Thanks,
David