Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
I believe, like a few others, that the error handling should depend on _WHAT_ the function is doing. For example, if you are trying to do a system call that fails, you should die (or at least set $! to the error). More importantly, you should document your module/sub to explain what the error handling procedures are. Here's how I feel error handling should be "handled":

1.) In the documentation, be very clear about what must be included, and which parameters are optional. To take an example, in Tk, you don't need to set the -background and -foreground properties of a window/frame/etc. It automagically falls on a default value. Let your users know this ahead of time. If you are handed more arguments than you need, then say that extra parameters will be discarded. There are basically two ways to handle this:
my $param1 = shift; my $param2 = shift; my $param3 = shift;
or
my ($param1, $param2, $param3) = @_;
I personally like the first, even though it is expensive. Pick whichever method you like and stick with it.

2.) I usually die when I have a fatal system error (as mentioned above), warn when I have a not-so-fatal error (say a log file is not available, but everything went fine), and return when there is something valuable to return. In a module I'm writing for my job, I do something like this:

a.) If I can not open the data source file (DB, text file, etc.), I die. There is no point to go any further as it will propagate more errors later on. Not only that, but they will be much harder to understand.

b.) If I can not open a log file, but everything is working, I warn. The code was written such that everything will be known to be going fine before the log is written. If anything has gone wrong before the logging code is reached, a die will occur. Again, no use propagating errors that are fatal.

c.) If there are no values (say, from a search) to return, I return an empty string ''. That way, someone can just check the length of the return value (or ref) to see if they got any useful data and do something with it.

3.) Error messages should be detailed enough such the user of such code knows why the error occured, and what the error was. Again, good documentation can save you a lot of thinking about how detailed error information should be inside of the module. You could simply say:

"This function will return 0 on failure." or "This function will die if a system error occured."

It all depends on how fatal you think the error is. Will it propagate more confusing errors? Then die. Do you want to just continue? Then warn. If you want to just return an error message or numerical status, then return.

Documentation is your best friend. If you use it well, then your error handling becomes trivial (or close to it).

Theodore Charles III
Network Administrator
Los Angeles Senior High
4650 W. Olympic Blvd.
Los Angeles, CA 90019
323-937-3210 ext. 224
email->secon_kun@hotmail.com
perl -e "map{print++$_}split//,Mdbnr;"

In reply to Re: What Are The Rules For Subs And Modules When Fed Wrong Input by Necos
in thread What Are The Rules For Subs And Modules When Fed Wrong Input by Cody Pendant

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, 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, 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.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others romping around the Monastery: (10)
    As of 2020-04-01 18:49 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?
      The most amusing oxymoron is:
















      Results (18 votes). Check out past polls.

      Notices?