in reply to How to say 'oops' in OOPs?

I used to return negative error codes from Mail::Sender's methods, but this leads to strange looking code. It's kinda hard to distinguish errors from valid responses. And I doubt anyone used the code returned anyway.

I'd say either return; in case of errors and set some $obj->{error} or die($with_message). And if the method doesn't need to return any value (if it's a command, not a "question") return the object itself. So that the users may stack the commands like this: 

$obj->cmd1(params)
    ->cmd2(params)
    ->cmd3(params;

[download]

Though this only works well if you die() on errors. Anyway you may leave the decision on the user. Current version of Mail::Sender let's you specify which style of error reporting to use: 

$sender = new Mail::Sender {
  ...,
  on_errors => 'die',
}

[download]
Whatever you choose DOCUMENT DOCUMENT DOCUMENT. Error handling is usualy the worst documented feature of modules.

Jenda
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
   -- Rick Osborne

Edit by castaway: Closed small tag in signature

Replies are listed 'Best First'.
Re: Re: How to say 'oops' in OOPs?
by Willard B. Trophy (Hermit) on Apr 08, 2003 at 17:13 UTC
    Thanks go to all. I think I'll go with the blank return;/$obj->errstr approach. I can see why one might do the die/eval thing, but it's not really my flavour of doing things.

    And yes, there is documentation.

    --
    bowling trophy thieves, die!

[reply]
      If the error is really unexpected, don't be afraid to croak or die. eval/die is comparable to try/throw in other languages. If the error is expected to occur, then undef is probably the best returned value.

      Personally, I think "return undef;" is more clear to the reader than "return;" even though they have an identical effect. Explicitly returning undef tells the reader that hey, dammit, the caller is probably watching for a false/undef return.

[reply]
        Personally, I think "return undef;" is more clear to the reader than "return;" even though they have an identical effect.

        Actually, they're not identical ;-)

        A raw return will return an empty list in a list context and undef in scalar context. This can make writing code that needs to behave itself in either context easier. See return for more info.

[reply]
[d/l]
        As adrianh said, a blank return actually equates to 
        return wantarray ? () : undef;

        [download]
        or probably more correctly 
        return !defined(wantarray) || wantarray ? () : undef;

        [download]

        Makeshifts last the longest.

[reply]
[d/l]
[select]

      You can always make the error handling behaviour an option. For example, DBI can be made to return errors, or throw an exception, depending on whether you pass the RaiseError option at object creation time.

      That way you can keep exception throwing freaks like me happy too :-)

      You might also find Best Practices for Exception Handling of interest.

[reply]
[d/l]
        That's a most useful reference; thank you. If I'd have found it first (and, to be frank, if Toronto Perl Mongers list management code hadn't barfed on my original message just 'cos it had sub in it) I might not have needed to ask. Mind you, the discussion here has taken interesting and useful (to me) directions.

        --
        bowling trophy thieves, die!

[reply]
[d/l]

In Section Seekers of Perl Wisdom