Re: I/O - exception handling

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Hyman Rosen wrote:
> The main problem is that when you get an error on closing a
> file, there's no recovery possible short of trying to recreate
> its contents somehow and somewhere. It's more like a hardware
> error than anything else.

But it is _still_ necessary to pay attention to this case. Using
fclose() in C (which GNAT calls upon), is a good example. If the
underlying fclose() fails this could represent a variety of serious
program flaws and/or media defects:

  - If there has been no prior Flush (or fflush in C), then this
    could be a "write error" for buffered data - this could have
    serious consequences.

  - If you have closed the underlying file descriptor that the
    File_Type (or FILE in C) is using, then unwritten data is
    also not getting out (In Ada this can be done by using
    POSIX.IO.Close(File_Descriptor) somewhere else in the code).

Basically, if close fails, this indicates that you most likely
have a serious code flaw, or at minimum, that you have a hardware
media problem (or possibly some other corruption problem).

IMO, the worst thing you can do is ignore the problem, unless
for example you are _expecting_ failures.

Maybe this is stating the obvious, but an example of this
might be where you might do this in C, where you want to be
sure that any files that were opened by the parent process, are
now closed:

   if ( !(PID = fork()) ) {
        /* In child process */
        for ( fd = 0; x < NOFILE; ++x )
              close(fd);   /* Ignore errors: close all files */

I think raising exceptions in close makes sense, because I have
not found too many programs that actually check that close succeeds.
Those same programs do not call fflush prior to the close either
(if they do, they don't check the result).  If this were an editor
for example, I would be extremely annoyed that the last 4K of my
code got truncated because the close()->fflush() call failed because
the file system returned ENOSPC!  I would expect that the editor
would then either keep my original source file somewhere else or
that I get another chance to save it, somewhere else.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg