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;
[download]

or

my ($param1, $param2, $param3) = @_;
[download]

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;"

---

---

• 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.