G'day Bod,

Many modules use a similar system to DBI. Text::CSV has the error_diag() method. The core modules in the IO::Compress:: namespace also do this: IO::Compress::Zip has $ZipError; IO::Compress::Bzip2 has $Bzip2Error; and so on. There are many other examples; it's a tried and tested model; there's certainly nothing wrong with using this approach.

Some of your points seem to indicate a single action to handle exceptions; I'd suggest there should be at least two: how you present problems to the user and how you present problems to the maintainer.

I don't know enough about your system but writing to STDERR should generally add to error_log (or similar). This is useful for the maintainer for troubleshooting; it wouldn't normally be available to the user.

Having some form of error page, or popup error panel, is what you should be presenting to the user. You can add a direction to include the message in a report to a sysadmin; but maintainers shouldn't rely on receiving this.

In addition to these "at least two", other actions such as emailing a report, or texting a notification, to a sysadmin may be appropriate.

How you present feedback to users will largely depend on the severity of the problem.

For a fatal error, an error page might have something like: "Database connection failed. Administrators have been notified. Please try again later.".

For problems with credentials (authentication or authorisation) you'd generally want to repost the page with an added message. A fairly typical example would be "Username/password mismatch. Please try again.". There might be a timeout or retry limit; it may be appropriate to advise the user of these.

There are situations where many things need to be validated; in a web context, this will often be a form. I tend to check as much as possible then present the user with a list of problems; e.g. "Name field is required", "Invalid date (31st November)", and so on. This allows the user to fix many things at once; presenting these one at a time can be very annoying. These messages might appear separately against individual form fields; they could be presented together in a list in a popup error panel; you might choose both of those.

I've aimed to keep my response as general as possible. If you have specific questions, please ask separately.

— Ken

In reply to Re: Error handling in a module by kcott
in thread Error handling in a module by Bod

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.