use Perl

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

  by samtregar (2699) on 2003.09.24 9:49 (#24499) Homepage Journal

  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

  Reply to This

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