in reply to Re: problems returning from recursive subroutine
in thread problems returning from recursive subroutine

I would offer that the reason to explicitly close everything is to tell your maintainer that you've done so.

Another, more important, reason is the same reason I always put the trailing comma in a list of stuff - what if I add more stuff?!? Then, the implicit close happens later, and that may not be good.

Of course, best, in my opinion, is to limit your exposure to connections like handles and $sth's to as small a block as possible, just in case.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

  • Comment on Re2: problems returning from recursive subroutine

Replies are listed 'Best First'.
Re: problems returning from recursive subroutine
by Abigail-II (Bishop) on Apr 18, 2003 at 13:32 UTC
    Should you then, for the same reason, undef your scalars, and empty your arrays and hashes when you are done, so your maintainer (if there is a maintainer...) knows you are done? Besides, if the maintainer doesn't understand that going out of scope means you are done with it, wouldn't you have bigger problems than not having an explicite close?

    Abigail

[reply]
      I make a distinction between connections to outside processes (like databases and files) and internal things (like variables and the like).

      The thing that bit me regarding this (because I always used to work with implicit closes) was prepare_cached(). The following snippet, within a function that's called repeatedly, will not work as expected: 

      sub oft-used_func
{
    ....
    if ($do_db_call)
    {
        my $sth = $dbh->prepare_cached($sql) || die;
        $sth->execute(@bind_vars) || die;
        while ($sth->fetch)
        {
            ....
        }
        # Use implicit close here
        # $sth->finish;
    }
    ....
}

      [download]
      The second time you do that DB statement, using prepare_cached() and not having called finish(), you will have a DBI error. Thus, I explcitly close all external things, but implicitly close all internal things.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

[reply]
[d/l]
        So, you think directories should be closed explicitely, just because you were once bitten by a database module that is not part of the Perl main distribution.

        Interesting. I was once bitten by a cat, therefore everyone should use a space between the array name and its index.

        Abigail

[reply]
        But that's DBI and prepare_cached, not a file or directory handle. Note that file and directory handles are resources Perl can natively deal with, while other handles allocated in an external process are not.

        Makeshifts last the longest.

[reply]

In Section Seekers of Perl Wisdom