Hello AppleFritter,
I don’t have much to add to hippo’s excellent answer. But:
I always regarded calling close as superfluous, unless I was either a) going to open the same file again (perhaps with different parameters, perhaps not), ...
Well, according to close:
You don't have to close FILEHANDLE if you are immediately going to do another open on it, because open closes it for you. ... However, an explicit close on an input file resets the line counter ($.), while the implicit close done by open does not.
But the real issue for me is (usually) not whether the file is closed, but whether errors are detected. A well-written programme should make it clear:
If a file error occurs after a successful call to open, an explicit close may be the best, or only, location in the code where it can be detected. This is so even when using autodie. For example (assuming the file “fred.txt” does not exist):
0:50 >perl -wE "open(my $fh, '<', 'fred.txt'); close $fh;" 0:51 >perl -Mautodie -wE "open(my $fh, '<', 'fred.txt'); close $fh;" Can't open 'fred.txt' for reading: 'No such file or directory' at -e l +ine 1 0:51 >perl -wE "open(my $fh, '<', 'fred.txt'); use autodie; close $fh +;" Can't close(GLOB(0x3bbb68)) filehandle: 'Bad file descriptor' at -e li +ne 1 0:51 >perl -wE "open(my $fh, '<', 'fred.txt'); use autodie;" 0:52 >
Hope that helps,
| Athanasius <°(((>< contra mundum | Iustus alius egestas vitae, eros Piratica, |
In reply to Re^3: Identifying unmatched data in a database
by Athanasius
in thread Identifying unmatched data in a database
by ardibehest
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |