in reply to Bad Module Code

I'm just attempting to write a module and was wondering if it is bad practise to have subroutines within the module that don't *return* anything?

It's actually pretty hard to write a Perl subroutine that doesn't return anything. For example, you might be surprised to learn that your sub returns 1 on success and undef if either of your system calls, open() or close(), fails.

Without an explicit return, the sub will return the value of the last expression evaluated. As luck would have it, close() will return 1 if it succeeds, so your sub will too.

When you use an empty return statement, the sub will return either undef or an empty list depending on the context in which it was called.

Perl only really lets you return nothing when the sub is called in void context (and a return value wouldn't be used anyway.)

-sauoq
"My two cents aren't worth a dime.";

Replies are listed 'Best First'.
Re: Re: Bad Module Code
by smalhotra (Scribe) on Jul 11, 2003 at 19:26 UTC
    In perl's spirit of DWIM (Do What I Mean) and its design for doing what comes naturally, your function (recopied below) may now *return* anything while returning a lot of useful information: 
    printFile($file) or warn "Could not printFile, '$file': $!";

sub printFile {
  my ($file) = @_;
  open FH, "<$file" or return;
  print while (<FH>);
  close FH; # do not complain if it cannot
}

    [download]

    Thanks to the design you will get a meaningful (undef) return if either the open or close fail. Aah, I love this language It does what you want it to do even when you don't think you told it to do anything. It's like perl can read my mind.
    $will->code for @food or $$;
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom