Programming style question on where to use die

[decnartne]

Is there any value in structuring a script such that subs return errors for main to die on rather than themselves die-ing on error?

rtfm's, links, nodes, etc. are all welcome - thanks in advance.

decnartne ~ entranced

[merlyn]

I'd use an error return value when an error return is a "normal" return. That is, a good portion of the time when the routine is called, it returns the "something went wrong" value.

I'd use an exception mecanism if the error is unexpected or rare, or it'd be difficult to test in normal usage. For example, the HTML generation functions of CGI.pm would be incredibly awkward to use if they had an error return value, because you'd be forever storing the result, testing it, and then moving along if it wasn't an error.

Just my 2-ish cents. {grin}

-- Randal L. Schwartz, Perl hacker

[jptxs]

My answer is no. As long as you do as perlsyn and the books suggest about what situation you should use a die in I think you should be fine putting the die in the subs rather than the main program. Just be sure to give a good error message chock full of info when you die - no matter where it's from.

One neat thing to look at when doing this is the caller function. This will help you spit out some interesting info about the situation when things went wrong. Also remeber to check $! (or $@ for dies from an eval) on the way out when appropriate. I like simple ones =)

"A man's maturity -- consists in having found again the seriousness on
+e
had as a child, at play."                                   --Nietzsch
+e

[jreades]

But let's not forget context -- useful error messages are all in the eye of the beholder.

For instance, if I'm batch processing files then I'd prefer to have the die() so that I can correct the error right away and get back on track. The more information, the better.

But if I'm a Web site visitor, I'd probably prefer to have the script die gracefully... in fact, I'd rather it gave me a simple message "Unable to complete request at this time, please click here to return to the page you were viewing. And then, of course, a detailed email message should be sent of to the site's programmers informing them of the problem and containing an much debugging information as possible.

It's all in the difference between programmers and end users, IMO.

[zigster]

Yes! there is great value a simple statement:
A function/method/sub should have one entry and one exit
If you uphold to this adage then your code will be more versitile, it is a damn site easier to add to subs that exit in a standard controlled way. The other problem is that in any meduium to large scale application you dont have enuff information to give a good message to the user only the calling sub has the context that your error messages need. What is the use of die'ing with a cant open file bob, if you dont tell the user why you wanted to open the file where it should be and what (s)he should do about it. Even if your code is simple the effort will bring reward if you ever try to add / build on that simple app (as functionality creaps).
Having said all that just to contradict myself for a moment. I do use die for situations that catagorically cannot happen (just to be sure that if they do I will get to know at source) if ever my programs call die from within a sub I do regard it as a bug to be fixed because it means that something that cannot happen just did ;-). --

Zigster

[runrig]

It really all just depends. On how serious the error is, how flexible you want the sub/module to be, etc. Look at DBI, for instance. You can set a RaiseError flag to raise an exception (die) on any error, or you can check the return value of any method, and get the error message through package or object variables.

[decnartne]

thanks for taking the time to reply - good feedback all around, and a couple ++'s to boot!

decnartne ~ entranced