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

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.

Apparently I did lose you. :-(

Yes, programs that die don't tend to carry on. But programs don't (or shouldn't) randomly do fatal things for no apparent reason.

Suppose for instance that a program tried to open a file that wasn't there, and then dies. It doesn't take long for me to figure out that the file isn't there, and it should have died. Fine. Now what do I do about it? Perhaps the file just needs to be replaced. Perhaps the programmer didn't realize that said file won't be there at certain times, and there should be an existence check and that step should be skipped. Perhaps the program needs to wait for the file to be replaced before progressing. Perhaps the program should have terminated as it did.

Lots of possibilities, and for a lot of them that line number will prove useful to me.

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

Okay - it would tell me where the contract violation was detected, not made :-)

croak() might not tell me either of course due to the evils of perls lack of encapsulation.