Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

SparkeyG (617)

  (email not shown publicly)

Journal of SparkeyG (617)

Wednesday September 24, 2003
09:05 AM

Let me decide when to die...

[ #14881 ]
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?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • 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 ge

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

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

  • What is this top secret phalanx project you mention?
  • 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