For the particular example CGI/DBI, I use a custom error-handling subroutine that does all the work for me. The only thing I have to pass (usually) is a simple error code, and perhaps the offencding SQL. For example: 
my $dbh = DBI->connect($foo,$bar,$baz,{AutoCommit=>1}) 
  or &Error(1);

my $sth = $dbh->prepare($SQL_TEXT) 
  or &Error(2,$SQL_TEXT);

[download]
The idea is to pass as little as possible, and let the subroutine deal with it. $DBI::errstr is already global, so it is not passed. The handy dandy caller function tells us exactly where this error came from. The error function then can react different ways, depending on the situation. For most users, it will display a "we are having probems with the database" message, log the error internally somewhere, and exit there (after some quick cleanup, e.g. $dbh->disconnect). For users that are markd as a "developer", a different error message is returned, this one usually has at least $DBI::errstr, the file and line number where it occured, and additional SQL used (formatted for the browser in pretty colors, of course, etc.) One of the biggest advantages to such an approach is the ease in which you can change things - say you want users to see a different message - voila! change it in one place, your error handling routine.

More specific errors, such as the wrong format in the field, should be caught before they go into the database, IMO. Javascript with a safety net of some simple perl checks go a long way towards making this happen. Avoid ever feeding a database "bad" data, as your program will have to rely on the DB's error message to figure out what is going on.

As far as making custom modules, I am a big fan of setting globals. In the case above, it really really helps that DBI sets $DBI::errstr and let's ME (e.g. the script) deal with it how I see fit. Sometimes I use the information inside it, sometimes I don't. I prefer methods that return simply true or false, then set a global.

In reply to Re: The art of error handling by turnstep
in thread The art of error handling by markjugg

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.