johngg has asked for the wisdom of the Perl Monks concerning the following question:

Normally one should check for success when doing file operations such as open. However, I wonder if there is a point to doing this if you are open'ing a filehandle against data held in a scalar reference. (I noticed that GrandFather didn't in this post.) If the script has compiled and is executing, in what way could the open fail? In this (slightly silly) code example

use strict; use warnings; open my $inFH, q{<}, \ <<END or die qq{open: $!\n}; The boy stood on the burning deck, Eating an ice cream, Walls. The ice fell down his trouser leg, And paralysed his left kneecap. END while ( <$inFH> ) { print qq{$.: $_} if m{([aeiou])\1}; } close $inFH or die qq{close: $!\n};

output,

1: The boy stood on the burning deck, 4: And paralysed his left kneecap.

my feeling is that checking for success on open and close are not needed and could safely be dispensed with. Is this a dangerous assumption?

Cheers,

JohnGG

Update: Thank you, jbert, kyle and Sartan for your responses. As happens, I am very likely to continue checking for success as it is already an ingrained habit and I wasn't even aware that one could open a scalar until recently. jbert, I thought your point regarding possible future implementations was particularly telling.

Replies are listed 'Best First'.
Re: Checking success of open() on file held in scalar ref.
by kyle (Abbot) on Nov 14, 2007 at 18:07 UTC

    I'd still check for an open failure for a couple of reasons.

    1. It's a strong habit. That is to say that I'd be checking for failure because I'm not really thinking about it.
    2. Future-proofing code (as already suggested by jbert). Just because I have nothing to fear today does not mean there will be nothing to fear tomorrow.
    3. It makes it easier to modify later. I may want to change it to use a real file. And then I may want to go back. I'd rather just have the die there all the time than keep adding and deleting it.
    4. I'm frequently surprised by things that don't work. In particular, it seems that open has many many special cases. Especially if my code has to deal with someone else's code, it's better to be defensive.
Re: Checking success of open() on file held in scalar ref.
by jbert (Priest) on Nov 14, 2007 at 17:17 UTC
    The checking is always worth doing, imho.

    Even if careful thought and analysis demonstrate that current versions of perl can't return an error, unless the docs give an explicit guarantee it won't fail I'd say that the behaviour is subject to change in future versions. (And said careful thought and analyis is more work than checking the error return anyway...)

    Maybe a future implementation of "open scalar" likes to have a dummy unix fd behind the scenes, to remove special cases in some codepaths and your process hit's it's limit? (Or other very hypothetical situations - who can come up with the most inventive?).

    Of course, if there were a significant benefit to dropping the error handling (or if you're in an environment where you don't care much), then fine. But that's true of anything, even exploiting explicitly undefined behaviour like my $foo if 0;.

Re: Checking success of open() on file held in scalar ref.
by Sartan (Pilgrim) on Nov 14, 2007 at 18:12 UTC
    I've run in to cases in my current job where checking for close is very important. If we have very little disk space(or no disk space), files can be open-ed(and created) since they just created an empty file but when we write to them and then try and close the file it fails. Knowing that the close failed allows us to do error recovery and try to write that file again later. It's saved us a lot of time - from time to time. Checking for open is always advisable otherwise you're going to print/read to a file handle you don't actually have.
      Suggest checking for print failure, as well as close failure, via 'print FH or die $!'. Use /dev/full for testing this otherwise hard-to-test condition.

        What OS contains /dev/full?

        --MidLifeXis