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.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.