package Class; 
sub new { bless {} }
sub method ($$) {my $self=shift; my $arg=shift }

package main; 
my $object = Class->new(); 
$object->method();       # OK
$object->method("foo");  # OK
Class::method($object);  # fails. Whines about arg count. 
&Class::method($object); # OK
[download]

Given this, if you have a routine that might do something particularly nasty when called incorrectly, you should probably just write some specialized checking into that routine. Generalized error checking for all (or even most) subs isn't worth the effort.

In Perl, the best way to ensure your client (meaning the person using your module) uses it correctly is to thoroughly document your interface. Trying to protect your module against all the mistakes that someone might make is laudable but it's probably not possible. Spending your time writing better documentation will pay off a lot more in the long run than spending it trying to code bulletproof error checking.

Perl's prototypes are useful if you need to have a function that acts (mostly) like a builtin but otherwise I suggest abstaining. You are probably better off not using them at all until you really understand what they are and how they differ from prototypes in other languages.

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

gav^

sub myfunc {
    my $arg1 = shift or (die|warn) "missing arg in myfunc";
}
[download]

die or warn based on severity of missing argument. But that's just me.

--
perl -e "print qq/just another perl hacker who doesn't grok japh\n/"
simeon2000|http://holdren.net/

I'd say that this is precisely the situation that Carp is designed for--use carp or croak rather than warn and die, and they'll know which invocation of the function they messed up, which is generally fairly useful information.

Alternatively, set $@, return undef, and let the caller figure out the problem. :-)




---

If God had meant us to fly, he would *never* have given us the railroads.
    --Michael Flanders

I rarely return undef explicitly, as it tends to do the wrong thing in list context. return by itself is shorter and smarter.

You could have corrected that. Simply select the post and the entry box will have your text. Simply type the correction and submit it. I don't think typo corrections warrent an update/edited message. However if you do change the content of a post, make sure you leave a note at the bottom of your original message that you did.

Update:

DOH! I guess I should read where the post is before I commnet. You can't update SOPW questions unless you are a janitor. Sorry for the wasted bytes! Thanks jeffa for setting me straight.