Warn the user that there's something wrong.

Okay. But "Something's wrong!" isn't very useful to the user.

According to POSIX, close can fail with one of 3 errors:

  1. EBADF: fd isn't a valid open file descriptor.

    Hopefully, if this can occur in the application, it'll be detected/sorted before the user gets his hands in it.

  2. EINTR: The close() call was interrupted by a signal; see signal(7).

    Ditto. If this is a possibility, a signal handler will have been installed to handle it.

  3. EIO: An I/O error occurred.

    And we're back to "Something's wrong!".

And then, the man page says:"A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes.", so even a successful close doesn't guarantee good data.

So we've told the user, "Something's wrong!, but not what. And even if we haven't told him, something could still be wrong. So where does that leave him?

He could decide to re-run the process to recreate the file; but what if it (whatever "it" is) happens again?

And, it could be he does so unnecessarily, because it was only the close that failed and not the preceding writes.

And what can he do about the failures that happen after we've closed the file; due to caching?

In the end, the only arbiter of whether the file is good is whether the next use of that file is successful.

So, the only sure way to detect the types of problems that might be indicated by close failing, is to ensure that the next process in the chain; even if that is a human being reading the file, can adequately detect that the file is incomplete or otherwise corrupted. Perhaps a sentinel record ("The end") or an known file size.

And whatever mechanism is put in place for the next process to detect the error; negates any purpose in detecting and warning that "Something's wrong!";

Did I miss a possibility?

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

In reply to Re^4: Scoping question - will file handle be closed? by BrowserUk
in thread Scoping question - will file handle be closed? by Monk::Thomas

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.