Steve, not using control-Y handlers or other trap handlers, writes:

> > 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.
...
> The form I use whenever possible is
>     OpenTheFileDatabaseWhatever();
>     if (TheResultMeetsMyRequirements)
>         {
>         DoAllTheThingsINeedToDo();
>         CloseIt();
...

That structure doesn't allow for control-Y handlers, or other
trap handlers, or other events that might lead to out-of-expected
sequence actions.  *That's* one major reason why it's important
to have appropriate cleanup code where you terminate the program.

However, if you examine the sentence:
> 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

then you see that my suggestion is still quite correct and the
best advise.  Using "CloseIt", we'd say:

   if database'is'open then
      CloseIt();
   ...other cleanup...
   terminate;

in your cleanup terminator...and thereby we adhere to your stricture:
CloseIt is called precisely when and where it is needed, and never
when it is not :)


> it's open"; CloseIt() doesn't exist except in code paths that
> guarantee the open-needs-to-be-closed state.

That's my point: in well written programs, you have to be aware
that multiple paths could lead to termination.  If they *don't*, then
I have to wonder about the robustness of the program :)


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

That's the worst part about closing a file...what value do I use
to indicate "this here is a non-open file"?

   MPE V:  0  (why? > 0 could mean it's open,
               and < 0 could mean it's globally open)

   MPE/iX: <0 (why?  0 could be stdin[x], but we don't have
               globally open files on MPE/iX (sigh))

              BUT...FOPEN returns 0 when it fails!

   HP-UX: -1  (why?  fopen() returns -1 when it fails)

So, I can't always use 0, and if I settle on -1, I'm ruling out
MPE/V (ok, so that's not so bad), *and* I have to do:

   fid := fopen (...);
   if <> then
      fid := -1;

(or, better: fid := no'file, where:   equate no'file = -1;)

Still...that "fid := no'file" just offends my sense of aesthetics.

I suppose I could use a cover function:

   if open'new'disk'file (status, fid, ...) = failed then
       ...do appropriate error handling, using "status",
          and fid happens to now have the value "no'file".
   else
      ...file is open, fid is some value other than "no'file".
Stan Sieler                                           [log in to unmask]
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler

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