Steve Dirickson writes:
>I'm going to disagree pretty strongly with this one. Especially since
>I have to admit that the misconception behind this thinking is much
>more widespread than I care for. To wit, "a good programmer puts a
>DBCLOSE in his/her termination path, just in case the database is
>still open."
Not at all. A program, like a procedure should have a single exit point,
at which all global-scope cleanup work is done. Scattering cleanup code
all over the program, at every point an error is detected, makes for an
unreadable program that will gain bugs as maintenance is done.
One of the things that MPE lacks is a supported, well-integrated language
with well-integrated database handling. In the absence of
language-mediated exception handling, the programmer must simulate it
with explicit transfers of control.
>Absolutely wrong: a *BAD* (unskilled, inexperienced, as opposed to
>"evil") programmer does things like that, because s/he doesn't know
>the state of the program!
Half-right. A good programmer does things like that because s/he knows
that it's not possible to know all possible states of a nontrivial
program. This means that the program must be designed so that unexpected
input conditions don't result in data structure damage. Placing all
cleanup code in a single section that is executed in response to
unexpected input conditions is a way of insuring that unanticipated
conditions don't cause data loss.
>A "good" programmer knows the possible
>states of the program at the entrance to and exit from each functional
>block, and thus knows, without uncertainty, when and where a DBCLOSE
>is--and is not--needed.
That's interesting. It implies absolute trust in the documentation for
all external code, and absolute trust in the people who wrote that
external code, and absolute trust in the people who keep the libraries
updated. It implies religious reading of all manuals at every update to
determine whether there are new return codes that your program doesn't
yet know about.
In fact, I'll go so far as to disagree absolutely: a good programmer is
one who knows that s/he *cannot* know the state of the program with
certainty at all times, and writes code in such a way as to insure that
unexpected state does not propagate.
>We aren't talking about exception handling
>here, where a "catch" block might gain control from any one of a
>number of execution states...
That's what *I'm* talking about: what is in effect a final "catch" block
that will insure that certain things happen. Most recent languages
include such a construct, but COBOL programmers have to construct such
niceties for themselves. And since they have to do it manually, a simpler
approach is better.
>--although, again, "good" programmers
>structure and partition their code such that exception processing is
>also built around limited, well-defined groupings of program state.
Again, this is practical only when there is language support for
exception handling.
>But, whether or not exception handling is used, liberal sprinklings of
>"prophylactic" FCLOSEs, DBCLOSEs, etc. at arbitrary locations
>throughout the code are not--ever--signs of a skilled practitioner.
Having exactly one DBCLOSE, placed where it will always get executed,
isn't exactly "liberal sprinkling".
-- Bruce
--------------------------------------------------------------------------
Bruce Toback Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc. (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142 | But ah, my foes, and oh, my friends -
Phoenix AZ 85028 | It gives a lovely light.
[log in to unmask] | -- Edna St. Vincent Millay
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
