"Though I'm sure it makes my code is more robust, I'm wondering at what cost."

The cost is time and extra effort, but the payoff is easier to troubleshoot, more robust and easier to update code.

Not only that, but it's experience for later projects; you get a very good understanding and knowledge of when you need to do deep validation, and when only a light skim will do. Not only that, but with good validation, your test suite can be (sometimes slightly) simpler... less edge cases to test against. You can for() loop a boatload of bad params at a sub in a test, and get back the same error/warning etc. if you've validated/checked them in the actual code. Get familiar with dies_ok() and throws_ok() from Test::Exception, and tricks to catch warnings, eg:

{
    my $warning;
    local $SIG{__WARN__} = sub { $warning = shift; };
    Module::do_something($param, $param1);
    like ($warning, qr/ignoring/, 'param 1 isn't an href, ignored');
}
[download]

Keep up the good work. The extra effort put in up front will pay off later when writing new projects, and when you come back to existing ones to make updates/fix bugs etc.

In my larger distributions, I typically use a named param public interface:

sub blah {
    my %params = @_;
    ...
}
[download]

...called like:

my $farm = blah(moo => $href, meow => "Phoebe's smelly cat");
[download]

...along with some sort of _validate_params() function/method, and sometimes a public function so a user can fetch all the valid params if desired. Here's a really basic example.

sub valid_params {
    my %valid = (
        moo => 1,
        woof => 1,
        meow => 1,
    );
    return %valid;
}
sub _validate_params {
    my %p = @_;
    
    my %valid = valid_params();

    for (keys %p){
        die "$_ isn't a valid param" if ! exists $valid{$_};
    }
    if (exists $p{moo} && ref $p{moo} ne 'HASH'){
        die "param 'moo' must be a hash reference";
    }
}
[download]

Then in each sub that accepts params:

sub yell {
    my %p = @_;
    _validate_params(%p);
    ...
}
[download]

Also keep in mind that the CPAN has some good modules for specific validations. Email::Valid for email addresses, Data::Validate::IP for v4/v6 IP addresses etc. Some of these validation distributions have been written by Perl heavy-hitters (the two I've mentioned certainly have), so if you've got a common type of param, do a quick search to see if someone has already written a validator for it. Sometimes the extra weight of an external module is worth it, sometimes it's not, but it's good to know these things are available if desired.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.