Re: Exception Misconceptions
In article <4b31d940$0$821$4fafbaef@reader5.news.tin.it>, "io_x" <a@b.c.invalid> wrote:
"tanix" <tanix@mongo.net> ha scritto nel messaggio
news:hgq10u$kk5$1@news.eternal-september.org...
In article <hgpvos$bo1$1@news.albasani.net>, Vladimir Jovic
<vladaspams@gmail.com> wrote:
James Kanze wrote:
Instead, he proposed to use a well designed logging system.
That way, you can identify problems with your code probably
10 times as fast as with debuggers.
could be 1000 times
could be i do it for hobby, but i like to follow what
really does one function after it is written, when born
Who does not?
The source code debuggers was one of the most important innovations.
It allowed to increase the speed and complexity of programs by
orders of magnitude.
This brings up an interesting issue about design.
There are two alternatives:
1) You do "good" design, meaning use all sorts of charts, diagrams
or what have you. Then specify things down to such a low level
that you even know all your return codes and all the arguments.
2) Intuitively see the overall structure and your idea.
Then, use this "top down design and bottom up implementation"
trick and lay down the lowest level, most fundamental "worker"
code, keeping in mind expandability issue and universality
of your code.
You see, whatever code you need to write, there will always
be this code that needs to deal with basic things, such
as file system access, network access, your basic structure
of data record or your low level video or sound functionality.
You'd have to do that no matter how you design what.
If you design an audio app, no matter what you do, you'd need
to have the lowest level code that deals with device drivers
and assures you can play whatever you need to play.
So, defining that low level code that you can immediately
use to test at least something, is probably the most profitable
investment of your energy into that project.
Then, you can go higher with your design and design some
code that sits on the top of low level stuff, keeping in mind
your overall architecture, that is still vague at this point,
even though you know what you are basically interested in
doing.
And so you SCULPT your program, instead of spending tremendous
amount of time during the initial desing. Because at that time
you hardly can see all the subtle interactions and have to
unnecessarily waste lots of energy trying to see what kind
of potential issues you might have in the future.
I had an experience once with one guy, who was extremist,
evangelical type. He just kept forcing everyone he had to
deal with to first spend months on design, without doing
a single line of code writing. So you forever grope in the
darkness.
There was one project we had to do. What HE did, was sitting
there for monts, scratching his head and writing down tons
of things in his grand design.
After a few months, he had a bible size book. When I looked
inside, I had goose bumps. Because the whoel thing was
"designed" down to exact algorithms, parameters and you
name it.
His idea was this: it may take me half a year on design.
But then it will take me 15 minutes to code that stuff.
How many people around would agree with that approach?
We had another project and I was the only one around that
could handle it. It was a relatively large database
application. When the bosses asked "how long do you think
it is going to take you to get something workable"?
I said: well, about a month.
The did not believe it. The said: ok, go ahead.
My programmer friend, who happened to be under influence
of that grand architect, said: you must be crazy.
You won't be able to do it even in two months,
and even if you WILL be able to get something to work,
I can break your code in seconds.
I said: OK. Let us see.
Within a month I had it working, pretty much to the day.
When I showed it to him and he wanted to humiliate me,
implying that my program is full of bugs and wont survive
for few seconds of heavy punishment, he sai:
Well, for me to break your program, I don't even have to
do much. I simply sit you a keyboard and simuplaneously
push ALL sorts of buttons non stop until your program
completely concs out, and so he did.
Yes, there was one moment when things stopped responding
just because he jammed so much shit into all the buffers
than even O/S could lock up.
But, after a couple of seconds we saw program giving you
a prompt again. Everything was working even under this
kind of abuse. He got pale on his face. He could not
believe it.
Now, that grand architect would probably take AT LEAST
6 months of doing it and I am not sure what he would
produce at the end, was not a subject to revision
even before he finished coding his 1st version.
The bottom line: it is a matter of personal style.
I, personally, like to see something alive pretty much
from the day one, and I do debug that thing from any
conceivable angle, pretty much from the start.
So yes, debuggers do help.
:--}
--
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.