What I often do in these cases is for the method/sub to return a hash.

(
  success => 0,
  data    => q{whatever},
  message => q{something horrible happened},
)
[download]

my %result = validate($arg1, $arg2);
if ($result{success}){
 # woot! we can continue
 # do something with $result{data}
}
else{
 # try again
 send_screen_back($result{message});
}
[download]

Or you could return an object that is overloaded so if the phone number is valid, the object is true in boolean context, and if the phone number is invalid, the object is false in boolean context, and gives the reason in string context.

But dying works as well. The caller should catch all calls though, which makes you do more work if only you're interested in valid/not-valid and don't really care about the reason.

Many options to choose from. None is "the best".

As a (further...) general comment, this is exactly the sort of situation where I find it very useful to employ Perl objects. (As many CPAN modules do.)

Basically, what you do is to “instantiate a new Perl object,” then “call a method to determine the result.” The method-call will dutifully return a response that is true-or-false ... but because you are talking to an object, the method can also quite-easily store an error-code for your subsequent retrieval.

my $foo = My::Verifier::Module->new();
if (!$foo->validate($number)) {
  print "You can't do that because $foo->error_message\n";
};
[download]

You may already have reviewed previous discussion on checking phone numbers. There are many existing modules dealing with phone numbers and you might want to adopt the error handling style of one of them.

sub validate_phone_num {
   return eval {
      /^$/ or die "No number\n";
      ...
      $cleaned_up_num
   };
}
[download]

I like this idea.

Is there any rule/praxis for or against setting $@ inside my modules or subroutines -- as a way of returning error messages?

If using above example as a guide, would the following module be considered to be "kosher" perl?

package Phone;
sub prettify {
    local ($_) = @_;
    return eval {
        /^$/ and die "No number\n";
        # do something to modify $_ here
        $_;
    };
}
[download]

In my main program this could then be called using:

my $pretty_number = Phone::prettify($number)
if (not defined($pretty_number)) {
    # e.g. insert message $@ into web page output
}
[download]

It is a bit odd. Why not let the exception propagate?

package Phone;
sub prettify {
    local ($_) = @_;
    /^$/ and die "No number\n";
    # do something to modify $_ here
    $_;
}
[download]

my ($pretty_number) = eval { Phone::prettify($number) }
   or do { ...insert message $@ into web page output...
           ...exit/return/next/etc...
         };
[download]

#!/usr/bin/perl -w
use strict;
sub chk_phn {
   local ($_) = @_;
   return "missing input" unless defined $_;
   return "empty input" if $_ eq "";
   return "invalid character" if /[^-\d]/;
   s/-//g;
   return (undef, $_);
}
my ($err, $res) = chk_phn @ARGV;
$err = "UNDEF" unless defined $err;
$res = "UNDEF" unless defined $res;
print "<$err><$res>\n";
[download]

Funny, I'm coding a schema validator too at the moment and returning hash (more precisely, hashref) like {success=>1, data=>..., ...} is also my preferred way.

Compared to the ($success, $res) tuple, hash gives you more flexibility as you can add more keys laters should you need one.

I'm too lazy creating "result objects" and I think it's an overkill anyway. Oftentimes you just want to give the user an error code and the output without much behaviour at all, so object is not particularly necessary here.

Exception is actually very handy, but I often deal with cross-language, cross-computer communication and convention about remote exception is not that well defined (at least in Perl?). Also I've always had this feeling that Perl5 is not really "exception-based". I'd wait for Perl6 for that, but that's just me of course.

A simple data structure like hash, on the other hand, is supported by virtually any decent programming language (even bash nowadays, I've heard).

There's another style which you could try:

$success = validate($data, $output);

$output is an optional argument which if given will be filled with the output by validate(). Sometimes you don't need the output at all and just need the fail/success boolean status.

“Do not do a thing already done.” Check CPAN.

use Food::Product;
my $p = new Food::Product('Tomato')
   or die("Could not instance Food::Product: ($Food::Product::errstr)"
+);

$p->isle(14);
$p->stock(450);
$p->sell(450) or die($p->errstr);
$p->sell(40) or die($p->errstr);
[download]

package Food::Product;
use strict;
use LEOCHARRE::Class2; # you do this your way
use vars qw/$errstr/;
__PACKAGE__->make_accessor_setget(qw/isle stock errst/);

sub new {
   my($class,$arg)=@_;
   $arg 
      or $errstr = "Missing valid arg"
      and return;
   return { name => $arg }, $class;
}

sub sell {
   my($self,$count)=@_;
   $count 
      or $self->errstr('missing how much to sell ammount')
      and return;

   my $now = $self->stock
      or $self->errstr('no stock left to sell from')
      and return;

   my $left_over = ( $now - $count ) ... some other rationalle
   $self->stock($left_over);
}
[download]

So in above examples.

• $Food::Product::errstr is a class symbol holding error string (potentially). These are class wide errors- maybe on compile, some config file should be present in the system- etc.
• Food::Product::errstr() is a method for the object- a regular perl setget method. This hold errors in regards to this one object. If you give it a bad name, a faulty parameter.. etc.

Check out DBI, has some similarities.
I used to fumble with this, wondering if maybe $error was better a label.. but errstr is pretty freaking common.

So, to answer more directly. In c, it's common to return if something is up- in perl, we return when it's all good. So, store any messages in the class or object as a separate value. Do NOT assume the coder wants to access further information if something fails. Just make it possible to get more information. Whatever you do- don't return only if there's an error etc- that would be poor form in perl.