Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Re: What Are The Rules For Subs And Modules When Fed Wrong Input

by Necos (Friar)
on Jul 23, 2002 at 21:40 UTC ( #184616=note: print w/replies, xml ) Need Help??

in reply to What Are The Rules For Subs And Modules When Fed Wrong Input

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;
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
perl -e "map{print++$_}split//,Mdbnr;"

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://184616]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (5)
As of 2020-04-10 10:41 GMT
Find Nodes?
    Voting Booth?
    The most amusing oxymoron is:

    Results (49 votes). Check out past polls.