carp - warn of errors (from perspective of caller)
cluck - warn of errors with stack backtrace (not exported by default)
croak - die of errors (from perspective of caller)
confess - die of errors with stack backtrace
The Carp routines are useful in your own modules because
they act like die() or warn(), but with a message which is more
likely to be useful to a user of your module. In the case of
cluck, confess, and longmess that context is a summary of every
call in the call-stack. For a shorter message you can use
which report the error as being from where your module
was called. There is no guarantee that that is where the error
was, but it is a good educated guess.
You can also alter the way the output and logic of
changing some global variables in the
namespace. See the
Here is a more complete description of how
What they do is search the call-stack for a function call stack where
they have not been told that there shouldn't be an error. If every
call is marked safe, they give up and give a full stack backtrace
instead. In other words they presume that the first likely looking
potential suspect is guilty. Their rules for telling whether
a call shouldn't generate errors work as follows:
Any call from a package to itself is safe.
Packages claim that there won't be errors on calls to or from
packages explicitly marked as safe by inclusion in
(if that array is empty)
. The ability to override what
@ISA says is new in 5.8.
The trust in item 2 is transitive. If A trusts B, and B
trusts C, then A trusts C. So if you do not override
, then this trust relationship is identical to,
Any call from an internal Perl module is safe. (Nothing keeps user modules from marking themselves as internal to Perl, but this practice is discouraged.)
Any call to Perl's warning system (eg Carp itself) is safe.
(This rule is what keeps it from reporting the error at the
point where you call
can be set to skip a fixed number of additional
call levels. Using this is not recommended because it is very
difficult to get it to behave correctly.
As a debugging aid, you can force Carp to treat a croak as a confess and a carp as a cluck across all modules. In other words, force a detailed stack trace to be given. This can be very helpful when trying to understand why, or from where, a warning or error is being generated.
This feature is enabled by 'importing' the non-existent symbol 'verbose'. You would typically enable it by saying
- perl -MCarp=verbose script.pl
or by including the string
in the PERL5OPT
Alternately, you can set the global variable
This variable determines how many characters of a string-eval are to
be shown in the output. Use a value of
to show all text.
This variable determines how many characters of each argument to a
function to print. Use a value of
to show the full length of the
This variable determines how many arguments to each function to show.
Use a value of
to show all arguments to a function call.
This variable makes
generate stack backtraces
. This is how
use Carp 'verbose'
is implemented internally.
This says what packages are internal to Perl.
report an error as being from a line in a package that is internal to
Perl. For example:
would give a full stack backtrace starting from the first caller outside of __PACKAGE__. (Unless that package was also internal to Perl.)
This says which packages are internal to Perl's warning system. For
generating a full stack backtrace this is the same as being internal
to Perl, the stack backtrace will not start inside packages that are
. But it is slightly different for
the summary message generated by
. There errors
will not be reported on any lines that are calling packages in
itself is listed in
Therefore the full stack backtrace from
will not start
, and the short message from calling
not placed on the line where
This variable determines how many additional call frames are to be
skipped that would not otherwise be when reporting where an error
occurred on a call to one of
's functions. It is fairly easy
to count these call frames on calls that generate a full stack
backtrace. However it is much harder to do this accounting for calls
that generate a short message. Usually people skip too many call
frames. If they are lucky they skip enough that
goes all of
the way through the call stack, realizes that something is wrong, and
then generates a full stack backtrace. If they are unlucky then the
error is reported from somewhere misleading very high in the call
Therefore it is best to avoid
. Instead use
The Carp routines don't handle exception objects currently. If called with a first argument that is a reference, they simply call die() or warn(), as appropriate.