Re^3: Friendly error trapping

This sounds like the question centers on issues of application design and having some sort of understanding of the user.

Regarding the conditions and information that the app needs in order to do its work for the user, you need to know by design what things are provided directly and explicitly by the user (command-line args, form parameters, dialog responses, maybe the contents of data files), and what things are determined by the OS/environment/config/etc (stuff that may be outside the user's control or awareness, including the contents of some data files). It can be easier to make the user understand the problem if they caused it and you can make that clear to them; if the problem stems from something other than their direct input, it might be harder to explain, but you should still try.

As for tying up any "internal" loose ends before exiting a script "properly" in case of a problem, this really depends on what the app is doing. If you intend to keep running (e.g. retry by taking the user back to a point just before a bad input), you need to know what steps, if any, need to be undone, what inputs need to be rewound, and so on. It's a difficult issue to discuss in general terms.

In any case, there's a good chance that users will find ways to break your code that you never thought of. Go ahead and give them some code to run anyway. Make some mistakes just like we all do, and if any particular problems vex you, come back with those.

UPDATE: In response to this part of your question:

Is it "safe" or "good practice" not to die? Or is there some intrinsic value of die that I am missing by not using it?

The intrinsic value of "die" is to acknowledge that for certain conditions, further execution is useless and futile. That's the point of using "die". This can be "contextualized" within an eval block, so that you can trap a bad condition without actually halting execution of the whole script -- that is, by putting a "die" condition inside an eval block, you're saying "further execution within this block is pointless" (but on exiting the block, the main script can still decide what needs to be done next).

Comment on Re^3: Friendly error trapping

Replies are listed 'Best First'.
Re^4: Friendly error trapping by bradcathey (Prior) on Sep 13, 2005 at 12:00 UTC
Points well taken graff. I'm embarrassed to say, I have not used `eval` to trap errors. How about a little lesson here... if I were to trap the error in the OP would it look something like this? `eval { uploader($dir, $name) }; print "There was a problem uploading your file: $@" if ($@); sub uploader { my ($upload_dir, $filename) = @_; ... open UPLOADFILE, ">$upload_dir/$filename" or die; }` [download] So, I can go ahead and `die` and the `eval` will trap and return the error without fatally terminating the script? Thanks! —Brad "The important work of moving the world forward does not wait to be done by perfect men." George Eliot	[reply] [d/l] [select]
Re^5: Friendly error trapping by graff (Chancellor) on Sep 13, 2005 at 19:06 UTC
Right -- just make sure you include some appropriate message with the "die" call, because that is what $@ will be set to; e.g.: `eval { uploader( $dir, $name ) }; print "There was a problem uploading your file: $@" if ( $@ ); sub uploader { my ($upload_dir, $filename) = @_; ... open UPLOADFILE, ">$upload_dir/$filename" or die "Open for output failed on $upload_dir/$filename: $!"; ... print UPLOADFILE ... or die "Output failed on $upload_dir/$filenam +e: $!"; ... close UPLOADFILE or die "Unable to close $upload_dir/$filename: $! +"; ... }` [download] If none of the die statements is invoked, $@ will come back undef and everything is fine; otherwise, $@ will be set to whichever message was passed to the die call, the thing uploader() was trying to do will have failed in some way, and the caller will keep running.	[reply] [d/l]


No such thing as a small change
	PerlMonks