Re: Cargo cults and the taxonomy of incompetence
- From: "John Jacobson" <jake@j[nospam]snewsreader.com>
- Date: Sun, 29 Oct 2006 12:43:49 -0600
Bob Dawson <RBDawson@xxxxxxxxxxx> wrote in message
<4544d591$1@xxxxxxxxxxxxxxxxxxxxxx>
What can one possibly say abou the thinking that went into this procedure?
I'm not at all sure how to formulate it, but there's certainly a level of
conceptual competence that makes those possessing it recoil in horror at the
above, while others simply don't see that the fuss is about: it works,
what's the problem?
That seems similar to something similar I once encountered. I once wrote the
following type of code block when I was in a hurry and had to make the code
more robust in light of network problems:
FMaxFRetries := 10;
fNumberOfRetries := 0;
while true do
begin
try
...do stuff that depends on network access...
break;
except
on E: exception do DecideRetry(E);
end;
end;
where DecideRetry was defined thus:
procedure DecideRetry(E: exception);
begin
inc(FNumberOfRetries);
if FNumberOfRetries >= FMaxretries then raise(E);
Sleep(FWaitingPeriodBetweenRetries);
end;
What I liked about this was that you could react to different types of errors
differently in DecideRetry by forking on different Exception descendents, like
EIdException. Perhaps there would be no need to retry stuff if it errors out on
an AV, but you'd want to retry on a EIdException, or at least give the user a
message to the effect that the network was having problems. There were several
sections of the code where the "while true do" loops were being used, but all
of them used the same DecideRetry function, so it would be easy to change the
way the entire app does retries. I wasn't too emotionally attached to the
"while true do" part of the retry loops. Repeat..Until(retries > maxretries) or
whatever, would work just as well just by altering that one function. So when
others decided to refactor the code (when under pressure to fix AV's they could
not figure out or tie to a line of code, in a product that was already several
months overdue) I saw no reason to complain, until they said that the reason
they wanted to refactor the code was that they did not think exceptions should
be allowed to alter program flow. They rewrote the code so that every function
in the stuff part captures all exceptions and returns a boolean, indicating
success or failure, writing the E.message to a global string. DecideRetry was
deleted and all the loops did their own test for the need to retry based on
whether or not true had been returned by the functions called. "While true do"
was replaced with a while( (FNumberOfRetries < FMaxRetries) and not Done) loop.
I obviously had no qualms about that last part.
But now they had code that wasn't passing very useful information up to the
calling code. Success versus failure, and a global error string they could
parse if they wanted to know what type of error had actually occurred. That was
it. In addition, now it became much more difficult to change the way retries
are done, because they had no common DecideRetry procedure that they can edit;
instead they must edit the retry tests in each and every block of code that has
to retry a network operation. In addition, in many parts of the code they had
try except blocks that simply cancel a database operation, without reraising
the exception, logging it or doing anything at all with it.
So, to summarize, their solution to a stubborn AV that they could not figure
out, was to remove object oriented exception handling and replace it with
procedural error handling. When I asked the guy that had decided that this was
going to be the way their refactoring was going to be done, a seasoned C/C++
programmer who hated Delphi, why they were going to do it this way, he said it
was the only way he knew how to make robust code.
This is a kind of problem I see a lot in Delphi projects, where methods that
may have been best-practices in other languages, like C, are forced onto Delphi
code by those who do not even bother to find out if they are best-practices in
the Delphi world. The time it takes to forcibly conform existing Delphi code to
old C practices could be spent acquiring mastery of the Delphi world, but, no,
too many seasoned programmers think they already know all they need to know
about programming, so they read no programming books, magazines or websites
anymore, and just keep applying the same practices over and over again wherever
they go, oblivious to the growing obsolescence of their approach.
--
***Free Your Mind***
Posted with JSNewsreader Preview 0.9.4.2919
.
- References:
- Cargo cults and the taxonomy of incompetence
- From: Bob Dawson
- Cargo cults and the taxonomy of incompetence
- Prev by Date: Re: Coding Horrors, Cargo Cult Programming, and other Ghoulish Things
- Next by Date: Re: Coding Horrors, Cargo Cult Programming, and other Ghoulish Things
- Previous by thread: Re: Cargo cults and the taxonomy of incompetence
- Next by thread: Re: Cargo cults and the taxonomy of incompetence
- Index(es):
Relevant Pages
|
