Re: Exception Misconceptions
In article <35f3b2ed-8303-4249-8b12-3f85b4907497@s31g2000yqs.googlegroups.com>, James Kanze <james.kanze@gmail.com> wrote:
On 19 Dec, 21:42, ta...@mongo.net (tanix) wrote:
In article
<668a7a4b-a2ee-4999-b3bc-5020bdac1...@k4g2000yqb.googlegroups.com>,
James Kanze <james.ka...@gmail.com> wrote:
[...]
Similarly, with regards to optimizing application code:
you've only got so much time to write it in, so it's often a
question of making it take 5 milliseconds less time (over an
hour), or adding a feature.
Well, to me, optimization is indeed one of the major criteria,
except I view optimization from the stand point of
architecture.
There are different ways to structure your code, or architect
the system.
The major criteria for me are:
1) Minimization of the size of executable,
which indirectly translates into correctness of your code and
flexibility of your structure and program architecture.
That's interesting, because memory use is one of the big costs
for garbage collection.
Forget about garbage collection on this thread I suggest.
I don't have that problem at the moment.
I have a different problem now. And that is win 7 related
problem of a perfectly good app with perfectly good, well
written NDIS device driver not working as advertized under
win 7. For one thing, it reports 2 more network adapters
than the XP reports. The names of those adapters are totally
diffetent than what XP reports. A major pain on the butt.
So, win 7 is no go for me. Because THAT app is the only
app I care about if I ever run windows of any kind.
Screw win 7. Does not worth it. Just becasue Microsoft want
to make another trillion bux and wasted at least 5 years on
developing this totally dead end win 7, does not mean I
have to buy into their trip.
I've actually used garbage collection
in C++ at times,
Wut?
and I know how to write C++ code which uses the
Boehm collector,
Good for you. I am impressed.
Cause I don't!
:--}
but for the application you described
else-thread, I wouldn't do it, because the memory overhead of
garbage collection is just too high (and because for that
particular problem, garbage collection just doesn't buy you that
much anyway).
I am not sure about this. But I trust your word on it.
I'd have to take half of the day to even think about it.
Sorry, can not afford it at this time.
4) Portability.
A tough one. Forget about it in the C++ world.
Such a major headache, that it is realistically undoable
unless you maintain several code bases.
With Java - a pice o cake. Non issue.
My experience is exactly the opposite.
WHAT?
Why are you trying to continuously insult my intelligence?
Not nice!
:--}
Java's portability is
limited to machines which have a good JVM.
Correct.
Which isn't many.
Well, about 90% of total market from what I know.
Good enough for a poor guy like me.
C++ works on pretty much everything.
True. No argument on that one.
Except of some REALLY nasty details.
5) Robustness.
And THAT is where these nasty exceptions come in handy.
You'll never be able to write a stable code, and I mean TRULY
stable, if you do not use exceptions.
Explain how applications have been running for years, without
interruption, and without using exceptions.
Well, THEORETICALLY, it can happen even without using exceptions.
In reality, it is just a joke.
For one thing, without exceptions your code becomes a huge pile
of spegetti code and I know what I am talking about.
So, it simply becomes more difficult to even see the subtle points
in your code because there is so much informational noise if you
do not use the exception mechanism.
You see, with exceptions, you have a rougher granularity of your
logic. For the applications I have to deal with right now it
translates into things like you have several levels deep in your
execution. If ANY kind of error happens on ANY of those levels,
you have a chance to hangle it on a local bulk level, vs.
checking every single call return result, which is really not
necessary.
Say, for example, you are establishing the network connection.
It does not much matter what kind of error you are going to get
even if you have to execute several methods to do that,
such as authentication or what have you.
All that matters is that you could have not established a
connection. Yes, you DO want to know why, but that can be
handled with a single exception. This is just an overall idea.
The same thing if you are downloading something from the
network. Even if you unplug the network wire in the middle
of no matter which level deep on the stack, you get at most
2 levels of exceptions. One is the lowest level network,
and the 2nd one is logical level of doing some operation.
Now, if you look at how many calls had to be made and how
many return codes you'd have to examine, it may be tens
if not hundreds, depending on what exactly you are doing
So, with exceptions you have only two things that trigger,
and if you user return codes, your code size and your
program logic becames twices as big and trice as complicated
with all those conditional spagetti code.
I do not know what kind of argument I can possibly provide
if you are so biased AGAINST exceptions. Sorry.
It is a psychology trip. Not a programing issue to me.
(The application in
question was written before C++ supported exceptions.)
Exceptions are a useful tool, for certain things, but like all
tools, you can do without (at some development cost) if you have
to.
Sorry. I can not agree with you on this one.
I think you are somehow predisposed AGAINST exceptions.
If that is the case, we will be arguing here untill our noses
go blue with no benefit that I can see.
[...]
So, exceptions should not be a part of your underlying logic.
They are your defense system against ANY kinds of problems.
You can NEVER assume that ANY operation is going to complete
without problems. In the middle of some routine, you may
loose power, just for the sake of argument.
In which case, you won't be able to process an exception.
True. But...
The trick is the program state logging.
You see. I can just turn off the power switch on my UPS off,
and after I reboot and restart the program, I am GUARANTEED
to continue on from the same exact point.
Why?
Well, because the very last successful logical operation
that resulted in the file update was logged and all the IDs
of relevant elements were saved. Yes, it IS a lil overhead.
About 1-2% I estimated. But the benefit can not be underestimated,
at least in MY situation.
Sure, if a nuclear war starts out, forget about those stinky
computers!
That means, that once you restart your program, and it was in
the middle of doing some heavy duty processing, you should be
able to recover and continue on, if at all possible, even in
principle.
So you need persistent transactions.
Correct.
You're not the first
person to need them, and a lot of applications use them,
including applications written long before anyone had ever heard
of exceptions.
So what?
I know for fact that what I do works MUCH better with exceptions.
You know why?
Well, because I originall had this code without exceptions.
But when I fully implemented the exception mechanism, I was able
to get read of probably 30% of my code, if not more,
and reliability probably went up a number of times.
I do not even know how to estimate it.
At this point, it is like a tank.
Unless you loose your entire hard disk, it is going to work
not matter what and not matter who says what for or against it.
I am just as pretty sitting with it as it gets.
[...]
I think all really competent computer scientists are purists,
Good. Keep them in museums then.
Nothing like taking a quote out of context, is there?
Well, there are ALL sorts of things in life.
Depends on what turns you on.
But to hear such a thing from YOU?
:--}
--
Programmer's Goldmine collections:
http://preciseinfo.org
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.