Re: Use of "die" in OO modules

[perrin]

Here are the rules I use:

• 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.

[theguvnor]

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.

[perrin]

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

[jrockway]

mmm, 69 == success.

[theguvnor]

I said:

a return code to signify what failed;

(emphasis added).

I fully realise that undef is a return code. It does not, however, carry information about what failed and why. The lack of defined return code is my signal to go off and look at my object/class and get the error.

That works for me (and as bryan notes above, is somewhat common in CPAN modules).

Your mileage might vary, as they say ;-)