http://qs1969.pair.com?node_id=459681


in reply to Re: Error Handling with Packages
in thread Error Handling with Packages

it seems to me that you have swapped croak and carp! croak dies, carp just prints warnings.

Anyway, usually, talking directly to the end user about some internals of the program is not a good idea... well, for scripts it is ok, specially if you are both the user and the programmer but for modules it's a bad idea, it doesn't escalate.

For most errors, the best think to do is to croak() and let the module user wrap the call in eval if he wants to handle the error in some way or just ignore it.

Sometimes, returning false and passing more information about the error in $! also makes sense.

Replies are listed 'Best First'.
Re^3: Error Handling with Packages
by Forsaken (Friar) on May 23, 2005 at 20:17 UTC
    Yeah, you're right, looks like I got them the wrong way around . As for talking to the end-user from a module, I think using carp for that is an elegant solution, especially when it's something that can be toggled on and off using a flag. For example: 
    package Foo;

use strict;
use warnings;

sub new
  {
  my($class, $debug) = @_;
  my $self = {};
  bless($self, $class);
  if($debug)
    { $self->{'Debug'} = 1; }
  return $self;
  }

sub bar
  {
  my($self, $hashref, @arguments) = @_;
  unless(ref($hashref) eq 'HASH')
    {
    if($debug)
      { carp "ERROR: first argument to \'bar\' must be a hashref"; }
    return;
    }
  #insert code here
  return $result;
  }

    [download]
    I find carp most useful for these cases. Personally I feel a module should never die on its own, that's my decision...

    Remember rule one...
[reply]
[d/l]
      to allow your module users to activate/deactivate warnings you can use warnings::register and warnings::enabled() instead of a custom aproach.
[reply]

In Section Seekers of Perl Wisdom