use Perl

• die() != exit() (Score:2)

  by samtregar (2699)

  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
  • Re:die() != exit() (Score:1)

    by kane (2600)

    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 [cpan.org] which you might find useful in this context.

    I use the same policy in CPANPLUS [cpan.org], since i do not want it to ever die.
    • Re:die() != exit() (Score:1)

      by perrin (4270)

      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() (Score:1)

      by grantm (164)

      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 (Score:2)

  by gav (2710)

  What is this top secret phalanx project you mention?
  • Re:phalanx (Score:1)

    by SparkeyG (617)

    Look here. [perl.org] Just another nod that maybe this needs a wider announcement. ;)
• dying is good (Score:2)

  by autarch (914)

  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