Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re: Catching errors in closing lexical filehandles

by graff (Chancellor)
on Sep 27, 2004 at 05:32 UTC ( [id://394070]=note: print w/replies, xml ) Need Help??

in reply to 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: $!" }
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.)

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.

      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.
        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: $!" };
        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
        Instead of:
        { use closefail; { open my $thing, $what or die "..."; # ... } }

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://394070]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (2)
As of 2024-06-15 05:35 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.