[sf-perl] Bad file number

Steve Fink sphink at gmail.com
Fri Jun 22 14:50:58 PDT 2007

On 6/22/07, Joe Brenner <doom at kzsu.stanford.edu> wrote:
> But as for the question "How many ways can close() fail"?
> That beats me, I've never looked into it.  What happens if you close
> a file that's been deleted by another process?  Or if it was a symlink
> that's been redefined in the meantime?  Or if it's on a partition that
> got filled up since it was opened?  Of if it's been flocked?
> Or if it's ownership/permissions has changed?

That wasn't the question. There are many ways for close() to fail.
There are very few ways that close() can fail and leave the file
descriptor still open. And for the specific problem at hand, that's
all that matters.

Again, I'm not going to argue with checking the return value of close.
It just won't happen to fix the problem in question.

Personally, I check the return value of close() most of the time, but
that's probably because I usually don't bother to close things
explicitly. :-) I believe in doing only the amount of error checking
appropriate for the application at hand. And in never trusting an
application not to disappear silently at any time without a chance to
clean up. A lot of people overuse kill -9. So checking for every
conceivable error is great, as long as you're not fooling yourself
into thinking you can reliably do something about it. Your program
could disappear before it reaches your error handling code anyway.

That said, I have a lot of "or die" statements in my code, because I
hate programs that just "don't work" without giving any hints as to
why. As long as something vaguely nearby the true cause of the problem
prints out a complaint, I'm happy.

I still refuse to check for errors on every print() call, though.

(And by the way, most of the reasons you list for close() failing
wouldn't actually cause it to fail. Not on a Unix-like platform, at
least. You're mixing up closing a file descriptor with "closing a
file" or "closing a directory entry" or something.)

More information about the SanFrancisco-pm mailing list