> Or it could indicate the opposite: a programmer who's very careful
and
> wants to make sure that a data base is closed cleanly. That means
s/he
> puts the DBCLOSE in the termination path of the program so that it's
> always executed, no matter what other failures (database or logic)
the
> program detects. This results in a spurious error message if the
thing
> that failed is the DBOPEN, but otherwise, it's sound practice.

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."

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! 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. We aren't talking about exception handling
here, where a "catch" block might gain control from any one of a
number of execution states--although, again, "good" programmers
structure and partition their code such that exception processing is
also built around limited, well-defined groupings of program state.
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.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *