Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Nice style for interesting error messages

by dash2 (Hermit)
on Jan 24, 2001 at 21:14 UTC ( #54046=perlquestion: print w/ replies, xml ) Need Help??
dash2 has asked for the wisdom of the Perl Monks concerning the following question:

I'm writing a module to do WHOIS lookups on domain names. The actual WHOIS lookup is relatively unusual for the following reason. Normally, interesting values are returned on the success of some method. Failure is uninteresting. So we use 0 or undef for failure. In a WHOIS, success is uninteresting: if a domain name is available, it's available. Failure, OTOH, is interesting: is the domain already bought? Or the whois server didn't respond? Or you couldn't contact the server? Or some internal script error?

So my question is, what is a nice way to handle "interesting" errors? I can think of a few:

1) Have failure return true (with an error message) and success false. Elegant, but counter-intuitive.

2) Have the subroutine/method return two values: success/failure, and an optional error message. Straightforward, but that extra value is going to waste space most of the time, and it's a bore to write your method calls always to expect two values.

3) Return true/false as normal for success/failure, and write to an object variable for the error message: e.g.
$success = $domain->do_whois() or print "Failed:". $domain->{whois_error}; I guess this is what the DBI module does. Perhaps this is best?

Opinions would be interesting. TMTOWDI and all that, of course, but I'd like to hear some views on the right way in particular situations.

Dave

Comment on Nice style for interesting error messages
(tye)Re: Nice style for interesting error messages
by tye (Cardinal) on Jan 24, 2001 at 21:39 UTC

    If success is uninteresting, then return an uninteresting result, that is, "". Then return the reason for failure (as a string, coded number, whatever) in the case of failure. system() already acts this way so it should not be too confusing for people (that is what documentation is for).

            - tye (but my friends call me "Tye")
      This sounds like what I wanted to suggest. So maybe you'd have:
      if (my $result = whois($foo) ) { #here we do something if the whois failed }
      or if you want something more intuitive, name the "whois" function "is_taken" or something. I'm not sure if memory-wise, the $result above would exist after the if statement, but it's only scoped for the if statement. If it is only allocated for the duraction of the if block however, that'd be a good way to not have an extra string/token sitting useless in memory for very long when whois succeeds.
Re: Nice style for interesting error messages
by Fastolfe (Vicar) on Jan 24, 2001 at 21:46 UTC
    Since "success" and "failure" seem to be pretty arbitrary, I might consider reversing the role of your function here:
    my $failure = is_taken($domain); print "Failed: $failure\n" if $failure;
    In the more general case, some modules tend to use $@ to store error messages, or a package-specific variable (say, $Lookup::errstr) containing the message:
    unless (lookup($domain)) { print $@ ? "$domain lookup failure: $@\n" : "$domain is available!\n"; }
      Please don't store anything into $@. Don't repeat Graham Barr's acknowledged mistake. $@ is documented as "errors from eval" only. User code shouldn't be pushed around in there.

      -- Randal L. Schwartz, Perl hacker

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://54046]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (6)
As of 2014-11-26 05:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (162 votes), past polls