leocharre has asked for the wisdom of the Perl Monks concerning the following question:

Working on a largish project, I have a ton of info to STDERR for watching what's up while the program is running.

I would have some errors and then it was tough to find them back in the code- I had a mountain of info on my error log. (using tail -f has been glorious)

For example, I know my sub will need scalar $a to hold a digit, if it doesn't- then I would normally output an error to STDERR, I felt that die was more holy, only for things that the system or perl would recognize as a real 'you are deadw, monkey' error.

lately, I realized that I should use die() a lot..?

1) Does this seem like it would help debugging, use die *whenever* something happens that should not happen? Is this a no brainer? What do other people do?

2) I've heard here and there that subs and scripts should ideally output nothing unless there's an error, is there any controversy to this amongst more experiences coders? Or is this basic mattured wisdom?

  • Comment on when to use die, questions about program feedback to the coder

Replies are listed 'Best First'.
Re: when to use die, questions about program feedback to the coder
by xdg (Monsignor) on Mar 09, 2006 at 16:39 UTC

    You might want to see "Style guide for error messages?" for some good discussion on this topic.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]
Re: when to use die, questions about program feedback to the coder
by izut (Chaplain) on Mar 09, 2006 at 16:39 UTC

    You can use 'warn' or 'die' to inform someone about errors. I wrote a module that mail someone the errors 'warn' and 'die' threw, based on merlyn's column. The module is called Carp::Mailer, and is available on CPAN.

    The easiest way to wrap them is assigning a subroutine to $SIG{__DIE__} and $SIG{__WARN__}. For further information check perlipc.

    Igor 'izut' Sutton
    your code, your rules.

[reply]
[d/l]
[select]
Re: when to use die, questions about program feedback to the coder
by davido (Cardinal) on Mar 09, 2006 at 18:29 UTC

    I can't claim to be an authority on these things, but here's my philosophy:

    Whenever any section of code does something that it shouldn't do, sees something that it shouldn't see, and that something will taint the reliability or hamper further meaningful execution, I throw a fatal (die). That includes subroutines and methods. In other words, if something fails to do its job, a fatal is thrown. That may seem rather draconian, but it makes debugging easier. And if at some point you should decide that it's ok for a subroutine to fail (for example) and for the script to keep running anyway, you can always trap the fatal using one of the standard techniques. I look at die as a hook. It can be trapped or it can be allowed to proceed to its default outcome (terminating execution).

    If a section of code does something it probably shouldn't do, but in a way that is not critical to ongoing execution, I'll throw a warning instead. Once again, if during debugging stages I wish to stop on warnings, I can promote them to fatals. If I wish to trap them for some reason, I can do that too. They're just another hook.

    That's my take on your first question.

    As for outputting nothing unless there's an error, I'm not 100% sure about that. It depends entirely on the script. For some things a progress report or status report might be good. Sometimes you might want a log of execution. There are legitimate reasons besides errors to output something

    I hope this helps, and hope it's sound/sane advice.


    Dave

[reply]
Re: when to use die, questions about program feedback to the coder
by cbrandtbuffalo (Deacon) on Mar 09, 2006 at 17:55 UTC
    If you are going down this road, consider Carp::croak and Carp::confess as well. They give a lot more info on the calling context when they fire and can make it much easier to track down where the error came from.

    If you do convert to throwing exceptions for errors, you can use evals in your calling code to control whether the exceptions will actually kill your program.

    There is a nice chapter in Damian's Perl Best Practices book on error handling too.

[reply]
Re: when to use die, questions about program feedback to the coder
by adrianh (Chancellor) on Mar 10, 2006 at 11:20 UTC
[reply]

Back to Seekers of Perl Wisdom