> Having code (at a single-point of termination) to close/cleanup
things
> is good.

As a blanket statement? We'll have to disagree on that one.

> But....one should NEVER unconditionally close files or databases...
> such code should always check if they're *open*.
>
> E.g.:
>
>    if base'is'open then
>       dbclose (...);
>       if status = 0 then
>          base'is'open := false;

The form I use whenever possible is
    OpenTheFileDatabaseWhatever();
    if (TheResultMeetsMyRequirements)
        {
        DoAllTheThingsINeedToDo();
        CloseIt();
        }
    else
        {
        ComplainAppropriately();
        }

or, if more appropriate
    OpenTheFileDatabaseWhatever();
    if (IDontLike--OrDontUnderstand--TheResult)
        {
        ComplainAppropriately();
        }
    else
        {
        DoAllTheThingsINeedToDo();
        CloseIt();
        }

In both cases, CloseIt() is called precisely when and where it is
needed, and never when it is not. And there's no need to "check if
it's open"; CloseIt() doesn't exist except in code paths that
guarantee the open-needs-to-be-closed state.

This last form lends itself to a violation of another "rule":
    OpenTheFileDatabaseWhatever();
    if (IDontLikeTheResult)
        {
        ComplainAppropriately();
        return (AppropriateErrorStatus);
        }
    DoAllTheThingsINeedToDo();
    CloseIt();
    return (SuccessCode);

Obviously this structure requires modifications when the code path is
dependent on multiple (almost) simultaneously-determined conditions or
(almost) simultaneously-obtained resources but, even in those cases,
it's usually not that difficult to retain most of the advantages of
the base form.

> I always do the "fid := 0" or "base'is'open := false", even if the
> next line of code is:  terminate;
>
> Why?  Someday, someone might add code inbetwee the two ... code that
> calls a routine that wants to use the file (or database) if
> it's open :)

Absolutely. When an item (resource identifier, flag, pointer, etc.)
that contains a value upon which other code objects depend for their
proper operation no longer contains a valid value, it should disappear
or become inaccessible; if it can't, it should be updated to contain a
value that can't accidentally be interpreted as a valid value by those
other objects. This includes overwriting the first two characters of
an exposed database name with spaces after it is closed.

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