NAME
Error::Unhandled - a Module for letting Errors do their own handling
SYNOPSIS
use Error qw(:try);
use Error::Unhandled;
try {
&foo;
} otherwise {
my $E = shift;
print "I caught:\n".$E->stringify."\n\n";
};
&foo;
sub foo {
throw Error::Unhandled(unhandled => sub {print "No one handled this.\n"; exit});
}
DESCRIPTION
While doing ASP programming, I wanted to use an object oriented exception handling system. Graham Barr pointed me at `Error.pm', which handled almost everything I needed. It was missing, however, a way for exceptions to define their own default error handling behavior. This can be very useful when ASP programming
The only difference in behavior between `Error::Unhandled' and `Error' is what happens when `throw' is called. The implementation of `throw' in `Error::Unhandled' uses `caller' to search the call stack, looking for `Error::subs::try'. If it finds one, it throws the exception as per normal behavior. If it doesn't find one, it calls `$self->unhandled'. Before doing that, however, it checks to see if the element `unhandled' is defined in its hash. If it is and it is a reference to a subroutine, it calls that instead. Note that if the element `unhandled' is present and is not a reference to a subroutine, `throw' will not call `$self->unhandled'. Finally, after all of that returns, `throw' will throw the exception as per normal behavior. If you don't want it to throw the exception, call `exit' or `die' within your `unhandled' subroutine.
It is, of course, also possible (and recommended in many situations) to sub class `Error::Unhandled' and provide a classdefined implementation of `unhandled'. Also note that both the instance-defined and class-defined `unhandled' methods receive `$self' as their first parameter.
Installation instructions
This module requires `Error', available from CPAN.
AUTHOR
Toby Everett, teverett@alascom.att.com