Let me decide when to die...

SparkeyG on 2003-09-24T14:05:40

I'm kwalitee testing Data-Calc for the phalanx project. This has been a very enlightening experience for me. I just stepped back into the testing mode today and realized why I stopped due to aggrivation before.

The Delta_Days function in Date-Calc croaks on invlaid data. I just hate when modules decide when to stop my program from running. Is it so hard to just return a error code? Am I the only one that is irritated at this?

---

die() != exit()

samtregar on 2003-09-24T14:49:30

Throwing an exception isn't an attempt to stop your program. It's an attempt to tell you there's a problem, and then stop the program if you try to ignore it. This is much better than a call which returns error codes and allows you to mistakenly ignore the error.

Consider, for example, print(). How often do you check the return value? But wouldn't you like to know if it didn't work in the middle of complex program? Exceptions allow the caller to program lazily (not checking return codes) and still get a wakeup call when something goes wrong.

-sam

Re:die() != exit()

kane on 2003-09-25T08:22:14

And i agree with the author -- i'm perfectly capable of deciding myself when a program should die.
And note that /none/ of the perl built-ins die if you do something that doesn't work.

To amend my frustration, i've written a module a while ago called No::Die which you might find useful in this context.

I use the same policy in CPANPLUS, since i do not want it to ever die.

Re:die() != exit()

perrin on 2003-09-25T16:14:59

If you want to see how bad people are about checking return codes, just look at DBI. Most DBI programs do not check the return of every method call, even though any one of them can return a code that indicates a catastrophic failure. The RaiseError option that makes DBI die when these things happen is a much better approach, since it ensures that your program will stop if it fails to perform a DBI operation unless you care enough to trap it with eval{}.

Re:die() != exit()

grantm on 2003-10-14T22:52:15

And note that /none/ of the perl built-ins die if you do something that doesn't work.

substr will die on when used as an lvalue and the range is invalid.

use & require will die on failure.

Various other builtin functions will die if the Perl binary lacks the relevant support.

phalanx

gav on 2003-09-24T16:41:06

What is this top secret phalanx project you mention?

Re:phalanx

SparkeyG on 2003-09-24T17:14:29

Look here. Just another nod that maybe this needs a wider announcement. ;)

dying is good

autarch on 2003-09-24T18:26:09

I agree with samtregar's post, as long as the behavior is documented.

In general, with my recent modules I've been trying to adopt a consistent behavior of "die on mutation, die on bad params, return false on accessor".

In other words, if you try to mutate/construct an object in an illegal way, it throws an exception. If a method takes parameters and you pass invalid parameters, it dies. If you try to simply retrieve some information that isn't available, it returns false.

This is, IMHO, a pretty sensible way to do things. If you try to do something impossible, it dies. If you pass in bad data, it dies. These are both _exceptional_ conditions, and merit a big reaction. OTOH, if you simply ask for data that can't be provided, I figure it's up to you to check the return value and handle the "no data" case however you see fit.