in reply to Uninitialized filehandles not as advertised?!

Works for me - maybe the problem is that you didn't show us where line 63 is in your code?

I used the following code and it runs without problems:

use strict; sub RLS_ropen($) { (@_ == 1) || die "RLS_ropen called w/ invalid argument list: ".sca +lar(@_)." params instead of 1"; my $name = $_[0]; unless ( $name ) { # invalid - null or empty file name return ""; } unless ( -e $name && -r $name ) { # file doesn't exits or is unreadable return ""; } open( my $dbh, "< $name"); return $dbh; } # end RLS_ropen my $fh = RLS_ropen "test.tmp";

... but maybe you want to be more explicit about things going bad, like for example, the file not existing:

open( my $dbh, "< $name") or die "Couldn't open database file '$name': $!";

Replies are listed 'Best First'.
Re^2: Uninitialized filehandles not as advertised?!
by Eli-Sko (Novice) on May 27, 2008 at 06:38 UTC

    maybe the problem is that you didn't show us where line 63 is in your code?

    Ahhh, so sorry worthy Corion, but immediately after the <readmore> block, I stated:
    where line 63 is (of course) open( my $dbh, "< $name"); almost straight out of the perldoc example.

    ...maybe you want to be more explicit about things going bad....

    The reason I just return instead of dying is that this is an interface, and the caller can use this routine to probe different paths / filenames until it finds the right one.

    And should you ask why I don't implement the search in the library, there are two answers: 1) because the caller needs to know where the data file is found, so that it can use that path to seek other files, as well, and 2) different programs calling this abstraction layer will have different search requirements.

    See? It all makes sense if you look at it carefully.