Adriano Ferreira

originally published in PerlMonks

Carp::Always is a minimalist debugging aid, often used from the command line with usage patterns like

perl -MCarp::Always script.pl

or

PERL5OPT=-MCarp::Always script.pl

Using Carp::Always decorates the output of each warn() and die() with stacktraces. For example,

$ perl -MCarp::Always -e 'sub f { die "arghh" }; sub g { f }; g;'
arghh at -e line 1
        main::f() called at -e line 1
        main::g() called at -e line 1

This is meant to help finding where issues actually coming from at the code being inspected.

Last week I had the chance to revisit Carp::Always code. It was basically abandoned since the 0.13 release back in 2013. One could say that there was not much work to do about it and that it withstood the test of times as many other CPAN modules that haven't seen updates in a long time. That is not quite true: the bug backlog kept growing and it is quite possible that the few Carp::Always users may have disbanded to newer alternatives like [mod://Devel::Confess].

The main changes in the latest 0.16 release are:

• Fix for a long standing bug with duplicate tracebacks - see a mention of it in the 2011 Perl Advent

• Carp::Always now enabled / disabled by import() / unimport() rather than using BEGIN and END blocks

The bug backlog has been cleared (both at GitHub and CPAN RT queue) to make room for brand new bugs. =)

Hopefully, these updates will extend Carp::Always lifetime and usefulness. You're invited to give it a try.

As a proof-of-concept, Importer::Zim has been released to CPAN. For modules which export symbols and define @EXPORT, @EXPORT_OK and @EXPORT_TAGS, zim can be used as a pragma to import subroutines into the caller package with lexical scope for perl 5.18+.

use zim 'Scalar::Util' => qw(blessed);
use zim 'List::Util' => qw(first sum max any all);

use zim 'Fcntl' => ':flock';
use zim 'Carp';  # imports carp(), confess(), croak()

use zim 'Mango' => 'bson_time' => { -as => 'bson_dt' };

Some of the benefits are:

• there is no need for Exporter-like code - only the declarations of the exported symbols are necessary.

• the imported symbols are self-cleaning - which means they won't pollute the namespace like it happens when exporting / importing is done through the symbol tables. (No need for modules like namespace::clean or namespace::autoclean.)

Importers are on the side of the consumer code - which is the one that should care more about the effect of the imported symbols. On the other hand, exporters are on the side of the producer code which can hardly anticipate every possible way its subroutines will be used. There are more good points on importers vs exporters at https://metacpan.org/pod/Importer#WHY?