Accessing the API¶

To install the new "fail" and "ON_FAILURE" keywords, simple load the module:

    use Lexical::Failure;

Changing the names of the API keywords

To avoid name conflicts, you can change the name of either (or both) of the keywords that the module sets up, by passing a named argument when loading the module. The name of the argument should be the standard name of the keyword you want to rename, and the value of the argument should be a string containing the new name. For example:

    use Lexical::Failure (
        fail       => 'return_error',
        ON_FAILURE => 'set_error_handler',
    );
    sub import {
        my ($package, %named_arg) = @_;
        set_error_handler( $named_arg{'fail'} );
    }
    sub inverse_square {
        my ($n) = @_;
        return_error "Can't invert zero" if $n == 0;
        return 1/$n**2;
    }

Signaling failure with "fail"¶

Once the module is loaded, you simply use the "fail" keyword in place of "return", "return undef", "die", "croak", "confess", or any other mechanism by which you would normally indicate failure.

You can call "fail" with any number of arguments, including none, and these will be passed to whichever failure handler the client code eventually selects (see below).

Note that "fail" is a keyword, not a subroutine (that is, it's like "return" itself, and not something you can call as part of a larger expression).

Note too that, as failure handlers operate at the interface level of a module, calling "fail" in a nested call within the package signals the failure from the package boundary (i.e. like "croak" and "carp" do).

Specifying a lexically scoped failure handler with "ON_FAILURE"¶

You set up a failure-signaling interface for client code by placing the "ON_FAILURE" keyword in your module's "import()" subroutine (or in a subroutine called from your "import()").

The keyword expects one argument, which specifies how failures in the module are to be handled in the lexical scope where your module was loaded. The single argument can be:

• a string containing the name of a named failure handler
• a reference to a variable, into which failure signals will be stored
• a reference to a subroutine, which will be used as a callback and invoked whenever a failure is to be signalled
• "undef" (or no argument at all), in which case "ON_FAILURE" does nothing. This means you don't need to bother checking whether a failure specifier was passed in to your "import()". Just pass in the resulting "undef" value...and it's ignored.

Typically, then, you have your "import()" subroutine accept an argument through which client code indicates its desired failure mode:

    package Your::Module;
    sub import {
        my ($package, %named_arg) = @_;
        ON_FAILURE $named_arg{'fail'};
    }

Then the client code can specify different reporting strategies in different lexical scopes:

    # Hereafter, report failures by returning undef...
    use Your::Module  fail => 'undef';
    {
        # But in this block, make errors fatal...
        use Your::Module  fail => 'croak';
        {
            # And in here, set a flag...
            my $nested_error_flag;
            use Your::Module  fail => \$nested_error_flag;
            {
                # And in here, any error is quietly loggged...
                use Your::Module  fail => sub { $logger->error(@_) };
            }
        }
        # Back to croaking errors here
    }
    # Back to returning undef here

Each "use Your::Module" invokes "Your::Module::import()", whereupon the call to "ON_FAILURE" installs the specified failure handler into the lexical scope in which "use Your::Module" occurred. The installed handler is specific to Your::Module, so if two or more modules are each using Lexical::Failure, client code can set failure-signaling policies for each module independently in the same scope.

Named failure handlers

If "ON_FAILURE" is passed a string, that string is treated as the name of a predefined failure handler. Lexical::Failure provides six standard named handlers:

"ON_FAILURE 'null'"

Specifies that each "fail @args" should act like:

    return;
    

That is: return "undef" in scalar context or return an empty list in list context.

Note that, this context-sensitive behaviour can occasionally lead to subtle errors. For example, if these three subroutines are using "ON_FAILURE 'null'" failure signaling:

    my %personal_data = (
        name   => get_name(),
        age    => get_age(),
        status => get_status(),
    );
    

then if any of them fails, it will return an empty list, messing up the initialization of the hash. In such cases, "ON_FAILURE 'undef'" is a better alternative.

"ON_FAILURE 'undef'"

Specifies that each "fail @args" should act like:

    return undef;
    

Note that to get this behaviour, the argument needs to be 'undef' (a five letter string), not "undef" (the special undefined value).

Note too that, when this handler is selected, "fail" returns an "undef" even in list context. This can be problematical, as an "undef" is (to many people's surprise) true in list context. For example, if "get_results()" returns "undef" on failure, the conditional test of this "if" will still be true:

    if (my @results = get_results($data)) {
        ....
    }
    

because @results will then contain one element (the "undef"), and a non-empty array always evaluates true in boolean context.

For this reason it's usually better to use "ON_FAILURE 'null'" instead.

"ON_FAILURE 'die'"

Specifies that each "fail @args" should act like:

    die @args;
    

"ON_FAILURE 'croak'"

Specifies that each "fail @args" should act like:

    Carp::croak(@args);
    

"ON_FAILURE 'confess'"

Specifies that each "fail @args" should act like:

    Carp::confess(@args);
    

"ON_FAILURE 'failobj'"

Specifies that each "fail @args" should act like:

    return Lexical::Failure::Objects->new(
                msg     => ( @args == 1 ? $args[0] : "@args" ),
                context => [caller 1]
           );
    

In other words, "ON_FAILURE 'failobj'" causes "fail" to return a special object encapsulating the arguments passed to "fail" and the call context in which the "fail" occurred.

See the documentation of Lexical::Failure::Objects for more details on this alternative.

You can also set up other named failure handlers of your own devising (see "Specifying additional named failure handlers").

Variables as failure handlers

If "ON_FAILURE" is passed a reference to a scalar, array, or hash, that variable becomes the "receiver" of subsequent failure reports, as follows:

"ON_FAILURE \$scalar"

Specifies that "fail @args" should act like:

    $scalar = [@args];
    return undef;
    

"ON_FAILURE \@array"

Specifies that "fail @args" should act like:

    push @array, [@args];
    return undef;
    

"ON_FAILURE \%hash"

Specifies that "fail @args" should act like:

    $hash{ $CURRENT_SUBNAME } = [@args];
    return undef;
    

Subroutines as failure handlers

"ON_FAILURE" can also be passed a reference to a subroutine, which then acts like a callback when failures are signalled.

In other words:

    ON_FAILURE $subroutine_ref;

causes "fail @args" to act like:

    return $subroutine_ref->(@args);

The availability of this alternative means that client code can create entirely new failure-signaling behaviours whenever needed. For example:

    # Signal failure by logging an error and returning negatively...
    use Your::Module  fail => sub { $logger->error(@_); return -1; };
    # Signal failure by returning undef/empty list,
    # except in one critical case...
    use Your::Module  fail => sub { 
                                  my $msg = "@_";
                                  croak $msg if $msg =~ /dangerous/;
                                  return;
                              };
    # The very first failure is instantly (and unluckily) fatal...
    use Your::Module  fail => sub { carp(@_); exit(13) };

Restricting how client code can signal failure

Because the call to "ON_FAILURE" must occur in your module's "import()" subroutine, you always have ultimate control over what types of failure signaling the client code may request from your module.

For example, to prevent client code from requesting "return undef" behaviours:

    sub import {
        my ($package, %named_arg) = @_;
        croak "Can't specify 'undef' as a failure handler"
            if $named_arg{'fail'} eq 'undef';
        ON_FAILURE $named_arg{'fail'};
    }

or to quietly convert 'die' behaviours into (much more useful) 'croak' behaviours:

    sub import {
        my ($package, %named_arg) = @_;
        $named_arg{'fail'} =~ s/^die$/croak/;
        ON_FAILURE $named_arg{'fail'};
    }

Specifying a module's default failure handler

In any scope where no explicit failure signaling behaviour has been specified, Lexical::Failure defaults to its standard 'croak' behaviour (see "Named failure handlers").

However, you can also specify a different default for your module, by adding a named argument when you load Lexical::Failure:

    # Default to full confession on failure...
    use Lexical::Failure  default => 'confess';
    # Default to 'return undef or empty list' on failure...
    use Lexical::Failure  default => 'null';
    # Default to instant fatality on failure...
    use Lexical::Failure  default => sub { carp(@_); exit() };

The values allowed for the 'default' option are somewhat more restrictive than those which can be passed directly to "ON_FAILURE"; you can specify only standard named handlers (see "Named failure handlers") or a subroutine reference.

If you need your default to be a non-standard named handler (see "Specifying additional named failure handlers") or a reference to a variable, you must arrange that in your "import()" instead. For example:

    sub import {
        my ($package, %named_arg) = @_;
        # Install failure signaling, if specified...
        if (defined $named_arg{'fail'}) {
            ON_FAILURE $named_arg{'fail'};
        }
        # Otherwise, default to pushing errors onto a package variable
        # (yeah, this is a HORRIBLE idea, but it's what our boss decided!)
        else {
            ON_FAILURE \@Your::Module::errors;
        }
    }

Specifying additional named failure handlers

The six standard named failure handlers provide convenient declarative shortcuts for client code. That is, instead of constantly having to create messy subroutines like:

    use Your::Module 
        fail => sub {
            return Lexical::Failure::Objects->new(
                        msg     => (@_ == 1 ? $_[0] : "@_"),
                        context => [caller 1],
                   );
        };

client code can just request:

    use Your::Module  fail => 'failobj';

However, you may wish to offer a similar declarative interface for other failure-signaling behaviours that your client code is likely to need. For example:

    use Your::Module  fail => 'logged';
    use Your::Module  fail => 'exit';
    use Your::Module  fail => 'loud undef';

Lexical::Failure provides a simple way to set up extra named handlers like these. You just specify the name and associated callback for each when loading the module:

    package Your::Module;
    use Lexical::Failure  handlers => {
        'logged'     =>  sub { $logger->error(@_);     },
        'exit'       =>  sub { say @_; exit;           },
        'loud undef' =>  sub { carp(@_); return undef; },
    };

The 'handlers' option expects a reference to a hash, in which each key is the name of a new named failure handler, and each corresponding value is a reference to a subroutine implementing the behaviour of that named handler.

Once specified, any of the new handler names may be passed to "ON_FAILURE" to specify that "fail" should use the corresponding callback to signal failures.

Note that any extra named handlers defined in this way are only available from the module in which they are defined.