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

True; as mentioned multiple times, the rules change a bit in the
presence of exception processing. Though I'd hazard a (totally
uninformed) guess that the percentage of real-world applications that
deal with breaks and traps is relatively low.

> That's the worst part about closing a file...what value do I use
> to indicate "this here is a non-open file"?
> ....
> 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".

That's the nice thing about object-based programming: 'fid' doesn't
have to be exposed to (casual) improper access or manipulation. It can
be wrapped up in an object that exposes, for example:
 operator =(short), which makes fidobject = FOPEN(...) work (HPFOPEN
requires a different approach)
 operator short(), which makes FREAD(fidobject,...) work, but which
can take action (log an error, throw an exception, ASSERT) if called
when the object does not identify a valid opened file

and which can take care of automatically closing the file--and, if
appropriate, logging the condition--if it is still open when the
object goes out of scope.

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