Re: Catching errors in closing lexical filehandles

I don't see anything wrong with doing it this way:

{
   open my $fh, $filename or die "open: $!";
   # do somthing with $fh 
   close $fh or die "close: $!"
}
[download]

Do you?

(update: BTW, according to perldoc, close returns true "only if IO buffers are successfully flushed". The relevance for closing an output file handle is obvious -- disks do fill up on occasion, and depending on your OS, there may be other things that get in the way of finishing output. But it's hard for me to imagine a case where this is important for an input file handle. Maybe if you're doing tricky stuff with input from sockets or processes, yeah, but in the typical case of a disk file or STDIN, the return from close shouldn't matter.)

(Another update, in response to your update: in the case of having multiple ways to exit the block, I usually make a habit of doing an explicit close on any sort of "premature return" condition involving an output file handle. Maybe that's an unnecessary compulsion on my part, but it just seems clean and coherent, like maintaining proper indentation.)

Comment on Re: Catching errors in closing lexical filehandles Download Code

Replies are listed 'Best First'.
Re^2: Catching errors in closing lexical filehandles by gaal (Parson) on Sep 27, 2004 at 07:54 UTC
As you must have gathered by my other responses by now, I don't think there's anything wrong in explicitly closing the file handle, except that I'd rather not have to do it :) The way I see it, I have a lexically scoped resource and when it goes out of scope, I want perl to free it for me. Of course on a low level that's exactly what it does, but the added DWIMmery of also doing something with possible errors here is just the kind of convenience I like having in Perl. Or from a slightly different tack: if this were a c function allocating memory on the heap, with the memory only being used inside the function, obviously you'd need to free() it before returning, no matter what. You don't undef your lexicals before you exit a Perl scope, do you? I think this sort of requirement in c is what led to the stylistic recommendation of having only one exit point for functions, because cleanup tends to be simpler, at least in theory. Once you don't have that pressure, the impetus to return in only one place lessens, and (to my mind, at least) exploiting scoping to do your cleanup for you becomes more attractive.	[reply]
Re^3: Catching errors in closing lexical filehandles by graff (Chancellor) on Sep 27, 2004 at 08:06 UTC
Yes, what you say about low-level C-like behavior vs. DWIM Perl-like behavior is sensible. But you have to bear in mind that the "default, typical usage" model in Perl is to proceed as if the specifics of various error conditions don't usually matter and you should be able to carry on regardless -- i.e. in the "generic" case you ignore error conditions, and only attend to them (with an extra line or few of code) when you feel a specific need to do so.	[reply]
Re^4: Catching errors in closing lexical filehandles by gaal (Parson) on Sep 27, 2004 at 09:19 UTC
Fine, which is why I'm okay with a declarative syntax for turning on the error handling (that is off by default). It can be something like `%SIG`, or come to thing of it, pragmatic behavior lexically defined. `use closefail qw(:standard); use closefail { die "I'm not feeling so well: $!" };` [download] There are plenty of ways this could be improved, I'm sure. for one thing, the naming is just the first thing that came to mind. One possible complication in implementing this, however, is that the scope of this declaration needs to include the closing of the current scope, if you pardon the pun. So you can say this: `{ use closefail; open my $thing, $what or die "..."; # ... } # <- still in effect as this block ends` [download] Instead of: `{ use closefail; { open my $thing, $what or die "..."; # ... } }` [download]	[reply] [d/l] [select]


No such thing as a small change
	PerlMonks