Can you think of circumstances in which close will fail? I do :-)If you say open my $fh, '>>', $file or die $!; you should also say close $fh or die $!; when done, IMHO
I'm gonna call you on this. Not because you are wrong, but because I haven't made up my about it mind yet.
Let's consider both scenarios when the close fails:
Dying at this point in the proceedings may waste whatever work was done till now, but the (this) output file hasn't been touched, so recovery probably consists of correcting whatever caused the failure and re-running the program.
Recovery is all together more complicated. The file has almost certainly been modified, but not in a consistant manner, so the error definitely needs to be recorded. Unless the application makes provision to record the file length prior to writing to the file, there is no possibility of automated recovery, as there is no way to determine how much was not flushed.
But dying at this point achieves nothing accept to ensure that all subsequent processing is aborted, which will often compound the problem--by leaving other persistance state in a indeterminate place--rather than alleviating it. </lo>
So, IMO, you almost never want to die on close failure, warn maybe, but not die.
Update: I also question the likelyhood of close actually failing, but that's probably a different discussion.
In reply to Re^3: using lexically scoped variable as a filehandle
by BrowserUk
in thread using lexically scoped variable as a filehandle
by varian
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |