Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re^2: Catching errors in closing lexical filehandles

by gaal (Parson)
on Sep 27, 2004 at 07:54 UTC ( [id://394094]=note: print w/replies, xml ) Need Help??

in reply to Re: Catching errors in closing lexical filehandles
in thread Catching errors in closing lexical filehandles

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.

  • Comment on Re^2: Catching errors in closing lexical filehandles

Replies are listed 'Best First'.
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.
      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://394094]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (2)
As of 2024-06-15 17:51 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.