Re^2: 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.

Comment on Re^2: Error Handling with Packages Download Code

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]
Re^4: Error Handling with Packages by salva (Canon) on May 23, 2005 at 20:44 UTC
to allow your module users to activate/deactivate warnings you can use warnings::register and warnings::enabled() instead of a custom aproach.	[reply]


Clear questions and runnable code get the best and fastest answer
	PerlMonks