http://qs321.pair.com?node_id=230807


in reply to Best Practices for Exception Handling

Also take a look at Exception::Class, which somewhat overlaps with Error.pm. The two can be used together pretty easily, however.

Replies are listed 'Best First'.
Re^2: Best Practices for Exception Handling
by adrianh (Chancellor) on Jan 29, 2003 at 11:47 UTC

    I'd add another vote for Exception::Class. It allows exceptions classes to be declared quickly and easily and has become my fave since discovering its existance.

    I tend to have a single module that declares all my exceptions. So for my Foo application I'd have something like:

    package Foo::Exceptions; use strict; use warnings; use Exception::Class ( 'Foo::Exception::DBI' => { description => 'DBI Error', # error => $DBI::errstr, }, 'Foo::Exception::DBI::Dupe' => { description => 'Duplicate key', isa => 'Foo::Exception::DBI', # error => name of duplicate key, }, 'Foo::Exception::Dupe' => { description => 'Duplicate entry', fields => [ 'name' ], # error => value of duplicate field }, # etc. );

    Comments are because Exception::Class objects have a default "error" field and I like to document what that should be used for where I declare the class.

    Throw exceptions like this:

    Foo::Exception::DBI->throw($DBI::errstr) Foo::Exception::Dupe->throw(name => $name, error => $value);

    Because of the closure issues raised by thraxil, I use the eval / if idiom instead of any of the modules that provide extra try/catch syntax.

    eval {$foo->something_that_might_die}; if (ref($@)) { if ($@->isa('Foo::Exception::Dupe') ) { warn "duplicate entry ", $@->name, " ($@)\n"; undef $@; }; }; die $@ if $@;