in reply to Re: How to get die() to stop printing a line number?
in thread How to get die() to stop printing a line number?

For me the question of where it died allows me to go there and start figuring out why it was doing what it did when it died. Therefore while where is in and of itself unimportant, it helps answer what I want answered.
  • Comment on Re: Re: How to get die() to stop printing a line number?

Replies are listed 'Best First'.
Re: How to get die() to stop printing a line number?
by Abigail-II (Bishop) on Jul 02, 2003 at 09:41 UTC
    In the example I gave, a die after a failure of a system call (which is a very common usuage of die), I would not look at the program to solve the problem - because the problem lies elsewhere. So, why bother with the line number? It's irrelevant to both the programmer and the user.

    Abigail

      And in the example you gave, a die after failure of a system call, I would look at the program to solve the problem.

      It usually doesn't take long to verify that the program had no way of succeeding in that particular operation. The question then becomes why it thought it might. Which means that I need to figure out what it was doing, and the line number is useful. In fact it is so useful that I prefer to use Carp's confess to get even more context at my finger tips.

      Furthermore I find automatic line numbers useful when a program has coding problems which I need to sort through to figure out the error. Coding problems like a program that did a chdir somewhere then died in the middle of a run (OK, I have the file name, where is that?) or ones that didn't bother including the name of the file that they were trying to open.

      And finally often after a batch script has terminated abnormally it is necesssary to decide what to do about the mess it left behind. The line number is useful for that because it gives me information about where the program was and therefore (if I know it) knowledge about what it was doing, what it had done, and what should be done about. (Yes, a well-designed program will clean up any mess before it does anything. I have not always had the luxury of using well-designed programs...)

      Now if the information is not useful for you, then you can readily ignore it. But it has been very useful for me, and I appreciate Perl automatically including it.

        And in the example you gave, a die after failure of a system call, I would look at the program to solve the problem.

        It usually doesn't take long to verify that the program had no way of succeeding in that particular operation. The question then becomes why it thought it might. Which means that I need to figure out what it was doing, and the line number is useful. In fact it is so useful that I prefer to use Carp's confess to get even more context at my finger tips.

        You lost me here. My programs don't continue after a die() (assuming it's outside of an eval), so I never have this "why did I think it would succeed" problem to solve.

        Abigail

      Sure there are many instances when the line number is a waste of space, but there are also instances where it's useful.

      For example I often use simple dies for checking for contract violations. Where the contract was violated is just as interesting as what aspect of the contract was violated.

      Line numbers sometimes good, sometimes bad - which was, I guess, your point ;-)

        Yeah, but a simple die() won't tell you where the contract was violated - it would tell where you found out that the contract was violated. croak() would tell you where the contract was violated though.

        Abigail