Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Re^2: Friendly error trapping

by bradcathey (Prior)
on Sep 13, 2005 at 02:17 UTC ( #491438=note: print w/replies, xml ) Need Help??

in reply to Re: Friendly error trapping
in thread Friendly error trapping

My question was simply this: is there something internal that die does that is necessary to exit a script properly?

The very point of this is to provide a more detailed error message, such as you describe, so the user does indeed know what the problem is without ungraciously dumping them in the middle of nowhere.

Update: To clarify, almost 100% of the time, this scenario is usually part of processing an HTML form which is uploading something or performing some file op, such as deleting a file. If there is an error, I use HTML::Template and HTML::FillInForm to re-display the form with the error message at the top so they can try again (or at least know what happened).

"The important work of moving the world forward does not wait to be done by perfect men." George Eliot

Replies are listed 'Best First'.
Re^3: Friendly error trapping
by graff (Chancellor) on Sep 13, 2005 at 03:38 UTC
    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).

      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; }

      So, I can go ahead and die and the eval will trap and return the error without fatally terminating the script? Thanks!

      "The important work of moving the world forward does not wait to be done by perfect men." George Eliot
        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: $! +"; ... }
        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.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://491438]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (4)
As of 2023-02-05 20:48 GMT
Find Nodes?
    Voting Booth?
    I prefer not to run the latest version of Perl because:

    Results (32 votes). Check out past polls.