I don't see the problem. The object could hold all that information without problem, and it's something you can serialize.

Yes, as I said, it can be done. It's just a quality-of-implementation issue. Today, plugin writers just have to write:

do_a();
my::Error::register(\&undo_a);
if ($do_c) {
    do_c();
    my::Error::register(\&undo_c);
}
do_b();
my::Error::register(\&undo_b);
[download]

and it all just works. The framework handles everything: remembering which recovery handlers have to be run, in which order, and saving this information for catastrophic failure recovery etc. Very tidy.

If each plugin had a single handler then all the work of remembering which parts of the plugin had been completed and which had not would have to be implemented inside every individual plugin's single error handler, with some package-global variable or variables set to track the current state, then those variables need to be stored somewhere so they can be recovered in the case of catastrophic error, and each plugin needs some kind of method that can be invoked to actually perform the recovery, etc. Instead of one single place, in the framework, implementing that behavior you're now pushing it out so that ALL the plugins have to re-implement it themselves.

But what I'd really like is to have the best of both worlds. So, is it possible / does anyone know how to take a string name of a sub and determine from that whether that sub actually exists?

Thanks!

If each plugin had a single handler then all the work of remembering which parts of the plugin had been completed and which had not would have to be implemented inside every individual plugin's single error handler,

Where'd you get that from? I didn't suggest removing any calls to register. I suggested you pass an object as argument.

do_a();
my::Error::register(\&undo_a, ARGS);
if ($do_c) {
    do_c();
    my::Error::register(\&undo_c, ARGS);
}
do_b();
my::Error::register(\&undo_b, ARGS);
[download]

to

do_a();
register_err_handler(a => ARGS);
if ($do_c) {
    do_c();
    register_err_handler(c => ARGS);
}
do_b();
register_err_handler(b => ARGS);

sub register_err_handler {
    my::Error::register( my::Plugin::ErrorHandler_->new(@_) );
}
[download]

The handler is trivial:

package my::Plugin::ErrorHandler;

sub new {
    my $class   = shift;
    my $handler = shift;
    return bless({ handler => $handler, args => [ @_ ] }, $class);
}

my %dispatch = (
    a => \&my::Plugin::undo_a,
    b => \&my::Plugin::undo_b,
    c => \&my::Plugin::undo_c,
);

sub handle_error {
    my ($self) = @_;
    $dispatch{ $self->{handler} }->(@{ $self->{args} })
}
[download]

This gives you a lot of flexibility (including the ability to serialise undo data) without messing with magic.

That said, given the details that recently came to light, yes, you might as well do

do_a();
my::Error::register(undo_a => ARGS);
if ($do_c) {
    do_c();
    my::Error::register(undo_c => ARGS);
}
do_b();
my::Error::register(undo_b => ARGS);
[download]

You can always pass an object as one of the args if if custom serialisation is needed.