I need to put the best face on the error and keep the program going.
You mean, if the code tries to open an output file and this generates an error instead of succeeding, you just want to tell the user something like "this probably won't work as intended..." or "no output is being saved, but we'll go through the motions anyway...", and forge ahead? Somehow that doesn't seem like the right thing to want. (Maybe I misunderstood the question.)

IMO, a vital element in writing software for use by others is to anticipate, as much as possible and reasonable, what can go wrong during execution due to factors beyond the scope of the software -- such as "disk full" or hardware/permission issues that make it impossible to save output to a file.

Among the things thus identified, if you can differentiate things according to severity (e.g. things that really make execution pointless/doomed vs. things that just disable some features), it's great to provide distinct and appropriate handling for each case.

But in any case, either you have to trust your users' ability to heed and understand your error and warning messages, or else you have to set yourself up to do some hand-holding when then come back to you asking what your error and warning messages mean.

The behavior of the code in the face of unsuitable conditions needs to be appropriate to the seriousness of the problem (not to any notion of "saving face"), but more importantly, the errors and warnings generated by the code -- and the documentation that accompanies the code -- need to be clear enough, and provide enough detail (but not a bunch of irrelevant detail), so that the user can understand both the problem and what needs to be done about it (or at least, the user can easily relay the message to you or some other support programmer who can figure it out if the user is clueless).

If you're talking about an interactive process where you need to tell the user things like "I couldn't use that last output file name you provided because ... -- please try a different path or file name:", that's a question of providing the appropriate user interface.

You should have an underlying model of the user(s): what they know and understand, what information they need to provide in order to make the software work, and what will be, for them, the most effective and least troublesome way to provide that information. With that, the error handling should fall into place pretty naturally.

In reply to Re: Friendly error trapping by graff
in thread Friendly error trapping by bradcathey

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.