The short fall of mirod's scheme is that is usually only one right answer, but there infinite wrong answers. For example, if I write some code that opens a file for reading, many things can go wrong. The file might not exist, the file might not be readable by the current user, the file might be empty, etc. If you are trying to give meaningful errors to the calling routines, you have exhausted the 0 or undef on failure option. All the calling code can do is say "Yup, something bad happened".

This gets even more complex when the low level routines are interacting with system(). To continue the example above, lets say the subroutine opens a file, reads a command from it and executes it via system() ( yes, security sucks, but this is an example ). You have not only the problems listed above, but now you need to worry about the error codes generated by the system() call as well.

My general method ( I am contemplating shining this up and attempting to present it at YAPC ) is I have a module that provides a series of simple functions ( Debug, Warn, Error, Usage, Notify ), a series of control variables ( don't print the message, die when Error is called, etc. ) and a whole slew of constants. The constants are defined in a hash, and the import routine makes constant functions of them and shoves them into the caller's space. There is one special value - NO_ERROR which is numerically 0. I use this since system() returns 0 on success ( it has some other interesting side affects ). The defined error codes are negative and any system() call returns the correctly left shifted response on error.

This allows the calling functions to determine if the error was internal ( eg, "Before I can do x, you need to give me y and z" ) or external ( eg, "That command does not exist" ). With a few more functions, you can even turn the numeric code back into something a bit more human readable.

Returning useful error codes is difficult at best. This is a long-winded statement of my current solution to this problem in the hopes it may help you. Sorry for the lack of code. If enough interest is given, I may clean the module up enough for the Catacombs.

Mik
mikfire

In reply to Re: The art of error handling by mikfire
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.