package autodie::hints;
use strict;
use warnings;
use constant PERL58 => ( $] < 5.009 );
our $VERSION = '2.06_01';
=head1 NAME
autodie::hints - Provide hints about user subroutines to autodie
=head1 SYNOPSIS
package Your::Module;
our %DOES = ( 'autodie::hints::provider' => 1 );
sub AUTODIE_HINTS {
return {
foo => { scalar => HINTS, list => SOME_HINTS },
bar => { scalar => HINTS, list => MORE_HINTS },
}
}
# Later, in your main program...
use Your::Module qw(foo bar);
use autodie qw(:default foo bar);
foo(); # succeeds or dies based on scalar hints
# Alternatively, hints can be set on subroutines we've
# imported.
use autodie::hints;
use Some::Module qw(think_positive);
BEGIN {
autodie::hints->set_hints_for(
\&think_positive,
{
fail => sub { $_[0] <= 0 }
}
)
}
use autodie qw(think_positive);
think_positive(...); # Returns positive or dies.
=head1 DESCRIPTION
=head2 Introduction
The L pragma is very smart when it comes to working with
Perl's built-in functions. The behaviour for these functions are
fixed, and C knows exactly how they try to signal failure.
But what about user-defined subroutines from modules? If you use
C on a user-defined subroutine then it assumes the following
behaviour to demonstrate failure:
=over
=item *
A false value, in scalar context
=item *
An empty list, in list context
=item *
A list containing a single undef, in list context
=back
All other return values (including the list of the single zero, and the
list containing a single empty string) are considered successful. However,
real-world code isn't always that easy. Perhaps the code you're working
with returns a string containing the word "FAIL" upon failure, or a
two element list containing C<(undef, "human error message")>. To make
autodie work with these sorts of subroutines, we have
the I.
The hinting interface allows I to be provided to C
on how it should detect failure from user-defined subroutines. While
these I be provided by the end-user of C, they are ideally
written into the module itself, or into a helper module or sub-class
of C itself.
=head2 What are hints?
A I is a subroutine or value that is checked against the
return value of an autodying subroutine. If the match returns true,
C considers the subroutine to have failed.
If the hint provided is a subroutine, then C will pass
the complete return value to that subroutine. If the hint is
any other value, then C will smart-match against the
value provided. In Perl 5.8.x there is no smart-match operator, and as such
only subroutine hints are supported in these versions.
Hints can be provided for both scalar and list contexts. Note
that an autodying subroutine will never see a void context, as
C always needs to capture the return value for examination.
Autodying subroutines called in void context act as if they're called
in a scalar context, but their return value is discarded after it
has been checked.
=head2 Example hints
Hints may consist of scalars, array references, regular expressions and
subroutine references. You can specify different hints for how
failure should be identified in scalar and list contexts.
These examples apply for use in the C subroutine and when
calling Cset_hints_for()>.
The most common context-specific hints are:
# Scalar failures always return undef:
{ scalar => undef }
# Scalar failures return any false value [default expectation]:
{ scalar => sub { ! $_[0] } }
# Scalar failures always return zero explicitly:
{ scalar => '0' }
# List failures always return an empty list:
{ list => [] }
# List failures return () or (undef) [default expectation]:
{ list => sub { ! @_ || @_ == 1 && !defined $_[0] } }
# List failures return () or a single false value:
{ list => sub { ! @_ || @_ == 1 && !$_[0] } }
# List failures return (undef, "some string")
{ list => sub { @_ == 2 && !defined $_[0] } }
# Unsuccessful foo() returns 'FAIL' or '_FAIL' in scalar context,
# returns (-1) in list context...
autodie::hints->set_hints_for(
\&foo,
{
scalar => qr/^ _? FAIL $/xms,
list => [-1],
}
);
# Unsuccessful foo() returns 0 in all contexts...
autodie::hints->set_hints_for(
\&foo,
{
scalar => 0,
list => [0],
}
);
This "in all contexts" construction is very common, and can be
abbreviated, using the 'fail' key. This sets both the C
and C hints to the same value:
# Unsuccessful foo() returns 0 in all contexts...
autodie::hints->set_hints_for(
\&foo,
{
fail => sub { @_ == 1 and defined $_[0] and $_[0] == 0 }
}
);
# Unsuccessful think_positive() returns negative number on failure...
autodie::hints->set_hints_for(
\&think_positive,
{
fail => sub { $_[0] < 0 }
}
);
# Unsuccessful my_system() returns non-zero on failure...
autodie::hints->set_hints_for(
\&my_system,
{
fail => sub { $_[0] != 0 }
}
);
=head1 Manually setting hints from within your program
If you are using a module which returns something special on failure, then
you can manually create hints for each of the desired subroutines. Once
the hints are specified, they are available for all files and modules loaded
thereafter, thus you can move this work into a module and it will still
work.
use Some::Module qw(foo bar);
use autodie::hints;
autodie::hints->set_hints_for(
\&foo,
{
scalar => SCALAR_HINT,
list => LIST_HINT,
}
);
autodie::hints->set_hints_for(
\&bar,
{ fail => SOME_HINT, }
);
It is possible to pass either a subroutine reference (recommended) or a fully
qualified subroutine name as the first argument. This means you can set hints
on modules that I get loaded:
use autodie::hints;
autodie::hints->set_hints_for(
'Some::Module:bar', { fail => SCALAR_HINT, }
);
This technique is most useful when you have a project that uses a
lot of third-party modules. You can define all your possible hints
in one-place. This can even be in a sub-class of autodie. For
example:
package my::autodie;
use parent qw(autodie);
use autodie::hints;
autodie::hints->set_hints_for(...);
1;
You can now C