Re: Use of "die" in OO modules

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.

Comment on Re: Use of "die" in OO modules

Replies are listed 'Best First'.
Re^2: Use of "die" in OO modules by theguvnor (Chaplain) on Jan 18, 2007 at 21:59 UTC
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]	[reply]
Re^3: Use of "die" in OO modules by perrin (Chancellor) on Jan 18, 2007 at 22:14 UTC
Uh, undef is a return code. I don't think that's any better than saying "79" indicates a failure.	[reply]
Re^4: Use of "die" in OO modules by theguvnor (Chaplain) on Jan 19, 2007 at 00:51 UTC
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 ;-) [Jon]	[reply]
Re^4: Use of "die" in OO modules by jrockway (Acolyte) on Jan 18, 2007 at 23:32 UTC
mmm, 69 == success.	[reply]