Opinions of Error.pm

harryf has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

Fielding for opinions. Have a code base where I essentially need Java-style exception handling (try/catch/finally etc.) - so far have used Carp (croak) and eval / if ($@) style reporting / handling but it's reached the point where I need to be able to "filter" for different categories of error and respond appropriately. Also want to avoid using some kind of convention based on the contents of the error message.

For example in calling some object method, which executes a SELECT statement, there could be some kind of fundamental (e.g. the db is down) or there might be something "wrong" with the data selected - an "application logic error". On encountering the application logic error, the process can continue but if the DB is down, the process should die.

Anyway - looking around, Error seems to be the most promising way forward (from this article). From experiments, it seems good but I'm nervous about introducing it because it's a such a fundamental change, and wondering how other people feel about it - stability / gotchas etc.

Some random thoughts / questions;

It doesn't seem too popular - I've yet to find any other CPAN modules using it. Why is that / have I missed something?
The module seems to have changed hands recently and had a long gap in development, between 2001 and 2006. Does anyone know the story here and if it's generally to be regarded as a stable API?
Being able to define my own exceptions and raise via Error::throw seems to work nicely and is backwards compatible with our existing eval {}; if($@){} exception handling. That's good news as we won't have to re-write everything but rather migrate in stages.
Less certain about try/catch/finally etc. provided by Error. It doesn't seem to handle errors raised via croak / die, which means we'd have to switch entirely to thrown exceptions plus re-throw any croaks from underlying CPAN modules we're using. In general, try/catch etc. seems to be where the most fundamental change would be and where the most "magic" is going on.
Any general feelings / experiences related performance overhead, memory use, garbage collection etc.? Have done some lightweight benchmarking so far and noticed no problems, but that could be a false positive.

The conclusion I'm starting to draw is "yes" to throw and "use base qw(Error)" but no to try/catch etc. - rather use eval like;

eval {
   doSomething();
};

if ( $@ ) {
    if ( $@->isa('my::own::error') ) {
        warn("Error occurred but may continue: $@");
    } else {
        # Catch other thrown errors, die, croak etc.
        die(ref $@ ? $@->stacktrace() : $@);
    }
}
[download]

Anyway - opinions / experiences very much appreciated.

Comment on Opinions of Error.pm Download Code

Replies are listed 'Best First'.
Re: Opinions of Error.pm by Excalibor (Pilgrim) on Sep 04, 2006 at 13:12 UTC
Greetings! I am using `Error.pm` at the moment on a relatively big project without much of a hussle. From this experience, using Error.pm is probably better than doing your own exception code for the following reasons: nice (and predictable) layout of exceptions hyerarchy (by using your own exception base class you get the whole thing, and it croaks when you try to throw an Exception you don't have) makes the checking easier (if you miswrite your class name on your examplo above, you'll never treat that exception right, but you cannot catch with (or throw) an unknown exception makes the code easily maintainable and easier on the reading than barebones eval/if($@), and this is Good(tm) My take on exception handling was this (just in case it may be useful to you), which is surely improveable, but I'm not going to touch it now ;-) use Error.pm as the base class of my hyerarchy of exceptions use 'throw' or 'die with' to generate exceptions use Log::Log4perl (but surely any other logging way will work) to leave the exceptions message (so that the information about the failure is logged down, and it's the type (or class) of the Exception what's propagated to the upper levels (so the log has detailed info about the failure, usually with different info at different logging 'depths' (i.e. simpler for ERROR but more verbose for DEBUG), and simple reasons for the exceptions messages themselves...) following Erlang's failure system, I just catch (by using eval or the module's :try keywords) the exceptions I know how to treat and let everything else to float up to the toplevel, where appropriate actions (usually dying) are taken briefly: extensive logging and a nice exception hyerarchy with the alternate constructors from Error.pm which make everything easier to read. Using try/catch with/catch/otherwise has worked nicely in some parts of the project and horribly in others (hosted Perl code which mangles with the C server that manages the Perl code, making dying really bad (lost place of dying, lost of cause and the stacktrace, etc...), so YMMV... Good luck! -- `our $Perl6 is Fantastic;`	[reply] [d/l]
Re: Opinions of Error.pm by rvosa (Curate) on Sep 04, 2006 at 17:57 UTC
I use Exception::Class to build exception hierarchies and Exception::Class::TCF for try/catch functionality. If a standard `die` is called inside a try block, Exception::Class::TCF turns it into an exception object (of class 'Default') through some clever jiggery-pokery. Might be what you're looking for.	[reply] [d/l]
Re^2: Opinions of Error.pm by astroboy (Chaplain) on Sep 10, 2006 at 03:12 UTC
Yep, I agree - I think Exception::Class::* is the way to go for exception handling in Perl	[reply]
Re: Opinions of Error.pm by adrianh (Chancellor) on Sep 04, 2006 at 18:11 UTC
It doesn't seem too popular - I've yet to find any other CPAN modules using it. Why is that / have I missed something? There was a long term bug that could cause a memory leak when it was used due to the creation of closures. Do a super search on the module and you should be able to dig up the refs. Personally I prefer the Exception::Class based modules.	[reply]
Re^2: Opinions of Error.pm by diotalevi (Canon) on Sep 05, 2006 at 02:36 UTC
This got fixed sometime during 5.8. Examine the change log to see how new your interpreter has to be. I don't plan to read the changelog for you. Also, be very, very careful when writing code that uses the return() call in eval/try/catch. You probably want to mandate that you don't want to use return inside any of those unless you really do know what you're doing. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re^3: Opinions of Error.pm by harryf (Beadle) on Sep 05, 2006 at 06:57 UTC
Interesting - will investigate Exception::Class. Thanks for all the replies.	[reply]
Re^3: Opinions of Error.pm by adrianh (Chancellor) on Sep 05, 2006 at 08:10 UTC
This got fixed sometime during 5.8. Examine the change log to see how new your interpreter has to be. I don't plan to read the changelog for you. I did say "was" :-)	[reply]
Re: Opinions of Error.pm by ftumsh (Scribe) on Sep 05, 2006 at 16:21 UTC
Matt Sargeant has a pdf somewhere. The upshot is not to use Error.pm. Do use Exception::Class Do use Fatal.pm Do use $SIG::{__DIE__}	[reply]
Re^2: Opinions of Error.pm by snowhare (Friar) on Sep 06, 2006 at 11:18 UTC
Do NOT, however, use $SIG::{__DIE__} in anything you intend to distribute through CPAN. More than once I have wasted an hour or two tracking a bug that was having its error messages swallowed by a CPAN module that blithely used an unlocalized $SIG::{__DIE__} handler for its own error processing and did not propagate unknown errors. Thereby stomping all over my application's own error handling (and any other module that might need to 'die'). It only takes one mis-use of $SIG::{__DIE__} anywhere in a body of code to mess it up for everyone. It is much too fragile for use in general release code.	[reply]
Re: Opinions of Error.pm by Anonymous Monk on Sep 05, 2007 at 21:02 UTC
Any thoughts on Exception-Base?	[reply]