Why Carp::croak over die?

[Irving Kimura]

I often come across the advice to use Carp::croak instead of die,
presumably because croak reports the error "from the perspective
of the caller", but I don't understand why this is generally
considered so much better.

If I'm interested in the caller's perspective, I use the Perl
equivalent of try/catch (i.e. eval/if($@)). This gives me access
to information both about the caller *and* about the called function.

Am I missing something?

Thanks!

Irv

--

 

[ctcgag]

I often come across the advice to use Carp::croak instead of die,
presumably because croak reports the error "from the perspective
of the caller", but I don't understand why this is generally
considered so much better.

If my module is dying due to some internal error, it should die.
If it is dying because the user did something wrong, it should croak.

If I'm interested in the caller's perspective, I use the Perl
equivalent of try/catch (i.e. eval/if($@)).

You wrap every single call to everything outside your own code in eval
blocks? I would think that that makes for butt-ugly code. And what do you
do in all those thousands of if($@) blocks?

This gives me access
to information both about the caller *and* about the called function.

Am I missing something?

Yes. Clean, readable, simple code.


Xho

 

[Ben Morrow]

I often come across the advice to use Carp::croak instead of die,
presumably because croak reports the error "from the perspective
of the caller", but I don't understand why this is generally
considered so much better.

If I'm interested in the caller's perspective, I use the Perl
equivalent of try/catch (i.e. eval/if($@)). This gives me access
to information both about the caller *and* about the called function.

Am I missing something?

Carp is for use in modules, where the error message is addressed to the
user of the module. That is, if you write a module:

package Foo;

sub bar {
my ($file) = @_;
open my $FH, '<', $file or die "can't open $file: $!";
}

and put it up on CPAN, a user will be rather confused when they supply
the name of a nonexistent file and it dies with '...at Foo.pm line xxx'.
They would have to grovel around in the source of your module to work
out what they'd done wrong, and try to trace the logic back to find out
where they had called Foo::bar with an incorrect argument. If, however,
it dies with '...at footest.pl line yyy' they can immediately see where
their mistake is, and correct it.

Carp doesn't actually simply report from the perspective of the caller.
It is quite clever about working out where the actual mistake was; for
instance

package Foo;

sub bar {
baz @_;
}

sub baz {
open my $FH, '<', $_[0] or croak "can't open $file: $!";
}

will report the error as coming from the caller of Foo::bar, even though
the croak happened in Foo::baz.

When I'm writing modules, I use carp/croak for things which are the
user's fault, and warn/die for things which are my fault (obviously,
such things never happen .

Ben

 

[Irving Kimura]

When I'm writing modules, I use carp/croak for things which are the
user's fault, and warn/die for things which are my fault (obviously,
such things never happen .

That's very helpful. Thanks,

Irv

--