in reply to Re^7: Scoping question - will file handle be closed?
in thread Scoping question - will file handle be closed?

Given that close can only return 3 errors; and two of those shouldn't be possible in tested code;

it's hard to see how croak("E: Unable to close file handle for $file: $!");

can "results in a nice explanation what went wrong".


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!

Replies are listed 'Best First'.
Re^9: Scoping question - will file handle be closed?
by Monk::Thomas (Friar) on Jul 14, 2015 at 21:48 UTC

    Maybe you are expecting something else? I find

    E: Unable to close file handle for /tmp/testfile: Bad file descriptor at /tmp/close_error.pl line 19.

    to be a nice explanation.

      It's a nice explanation of something that should happen once you've tested you're program.

      Ie. It is a programmer error; not a user error. There is nothing user can do about it. Ditto;: EINTR.

      That only leaves: EIO: An I/O error occurred. which a) tells the user nothing beyond "Something's wrong!"; b) May cause them to re-run the process for no reason.

      Which takes us full circle back to Re^4: Scoping question - will file handle be closed?.


      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!

        Hmm. You asked what could be done if a close fails and my suggestion was to at least notify the user that something bad has happened, which file is affected and maybe even provide a general idea what the problem is. At the very least that should help the user to provide the programmer with ~some~ useful information. (instead of crashing silently or simply turning a blind eye)

        EBADF should be taken as a sign there's an actual bug. EINTR/EIO would enable the programmer to say: There's something fundamentally wrong with your system, don't bother me. The filename could help to figure out which filesystem / disk is having a problem and to perform a cross-check with the syslog if it has anything to say about it.