People have their various opinions about this, and I'm generally against dying in a module only because most of Perl doesn't do that. I want to be consistent in my error handling rather than introducing a new way with every module I use.

The modules I find that annoy me, however, are the ones that die for the wrong reasons. Sometimes I don't care if the call failed, but it shouldn't stop my program if it does. That's a lot different than not being able to connect to a database or open a necessary file, where I probably do want to think about what's going on and how to recover from it.

So, that's not really an answer. If you are going to do that sort of thing, though, use Carp's croak instead. That way the filename and line number in the error message come from the place it was called insted of inside the module, which isn't very helpful.

I have a chapter on "Detecting and Reporting Errors" for Mastering Perl. Despite my personal bias I try to present both sides fairly. :)

It is also difficult to come up with a consistent failure convention. Using undef is a bad idea as it is true in list context (any value is), and some functions will return undef as a valid response. -1 is less appropriate. You could bless an error object and return that, but that strikes me as an ugly solution.

I prefer to use Exception::Class, or if I am feeling lazy then die will do. Perl Best Practices has an excellent chapter on Error Handling (13) - I highly recommend it.

Thanks for your input, though I should have specified one thing more clearly: when I said I return (undef), I meant that I just return;, I don't return undef;. I'm aware of the problem with returning undef explicitly.

(For the unaware: a bare return gives the caller an undef, regardless of whether the call was in scalar or list context. Returning an explicit undef gives the caller undef in scalar context and a list containing one element (undef) in list context.)

[Jon]

I like to use Exception::Class to throw exceptions. If the caller wants to ignore my gravely important problems, it will have to do that explicitly. It's nice to have a module that contains all the exceptions I'll want to throw. It looks like:

package My::Exceptions;

use Exception::Class
    (
     'My::Bad' =>
     { description => 'Way bad', },
     'My::OtherBad' =>
     { description => 'Bad as well',
       isa => 'My::Bad', },
    );
1;
[download]

Then anywhere I need them, just use My::Exceptions and My::Bad->throw( error => 'Woe is me' ).

I tend to use various methods from Carp when I'm building OO things. I can die places my module is broken and croak places where the caller did it wrong. There are a lot of choices in Carp, but I think croak is probably what you need.

I figure the caller can always eval { $object->something } if they need to.

UPDATE: The more I think about it though, I really only die (croak) when arguments passed differ unusuably from the documentation.

• Never use return codes to indicate failure. People will forget to check them and you will have silent failures. It's happened to me too many times.
• If I want to be able to tell which thing failed, I use Exception::Class objects. You can compare them with $@->isa('Foo'). That's much easier than trying to parse error messages to see which thing died.
• If the error is not something I can handle and continue on, i.e. I just want to log it and send a friendly error page to the user, I just use Carp::croak(). Nearly all unexpected errors (like a failed database connection) are like this.

And I second the idea of not using a return code to signify what failed; I do however condone letting undef indicate that there is an error (that can be inspected some other, appropriate, way) if there's no potential for undef as a valid data return.

[Jon]

Uh, undef is a return code. I don't think that's any better than saying "79" indicates a failure.

$HOLY_WARS--

I recently added a ErrStr var to my modules, kinda of like the DBI::errstr. So if the object constructor fails the object is an undef and the the Errstr can be checked, i.e.

       my $obj = Some::Module->new() or die $Some::Module::Errstr, $/;
[download]

...otherwise if there is an error with a method call the error string can be retrieved,

      $obj->get_errstr();
[download]

I really struggled with what was the correct way to handle the errors, I'm still not sure I like my solution.

DBI is a module with a very wide audience. So there may be a reason why to support the behaviour of RaiseError = 0. But I with newly developed in house module I don't see any.

I'm going crazy (and rude) when I see my colleagues to write their code like this:

my $dbh = DBI->connect($data_source, $username, $password, \%attr) or 
+die $DBI::errstr;

...
my $sth = $dbh->prepare(...) or die $DBI::errstr;
[download]

Why rude? Because

1. There is usually (always) nothing to do if the DBI method fails but die. So why to bother with return value and clutter you code with unnecessary die
2. If there would be something to do (probability 0.001%) writing the eval block is as easy as checking the value returned.

And why they write their scripts this way? Because they saw it in DBI perldoc.

This should be probably a topic of a new meditation but that is how the whole Perl works. You start with "There is more than one way how to do it" and then you will need the very clever (no irony) "Perl Best Practices" book to tell you that all the ways but one are wrong.

You can put me in the "use exceptions (plus Exception::Class if you need to return more than just 'an error happened'" camp.

My reasons for this still match the ones I wrote at Re^2: Best Practices for Exception Handling.

Thanks for the link - interesting reading. The whole raison d'etre for my original post was that though I philosophically fall into the same camp, I have problems with the implementation/execution - in the absence of true built-in Exception handling, I have to decide between a couple of options: either fake up a try/catch type of thing by using eval {...}; if($@){...} or go with the old return undefined and let the caller inspect the object's error() method.

[Jon]

in the absence of true built-in Exception handling

I'm curious, since I've heard others saying this, why you think Perl's exception handling isn't "true" or "built-in"?