in reply to when to use die, questions about program feedback to the coder

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

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