I am working on implementing exception handling in a object-oriented Perl application. Currently, I am looking at using Error.pm. In the synopsis section of the documentation for Error.pm (listed below), there are some interesting lines of code.

    try {
    do_some_stuff();
    die "error!" if $condition;
    throw Error::Simple -text => "Oops!" if $other_condition;
    }
    catch Error::IO with {
    my $E = shift;
    print STDERR "File ", $E->{'-file'}, " had a problem\n";
    }
    except {
    my $E = shift;
    my $general_handler=sub {send_message $E->{-description}};
    return {
        UserException1 => $general_handler,
        UserException2 => $general_handler
    };
    }
    otherwise {
    print STDERR "Well I don't know what to say\n";
    }
    finally {
    close_the_garage_door_already(); # Should be reliable
    }; # Don't forget the trailing ; or you might be surprised
[download]

In the except clause, exceptions are handled by a general_handler anonymous sub which sends a message. Then a hash of the exceptions are returned. How would this work in the context of an application? What is the philosophy of this kind of exception handling? How would a class that receives exception/error messages influence the decision-making of higher level classes?

In the case of my application, I need to process all the errors that occur during a make process and then make decisions based on the errors in higher level classes.

I am looking for examples in Perl of an object-oriented application that uses Error.pm. I am also seeking guidance in the design of exception handling and error handling in Perl object-oriented applications.