(To copypaste http://leonerds-code.blogspot.com/2011/03/carp-from-somewhere-else.html ):
Carp provides two main functions, carp and croak, as replacements for
core Perl's warn and die. The functions from Carp report the file and
line number slightly differently from core Perl; walking up the
callstack looking for a different package name. The idea being these are
used to report errors in values passed in to the function, typically bad
arguments from the caller.
These functions use the dynamic callstack (as provided by caller()) at
the time the message is warned (or thrown) to create their context. One
scenario where this does not lead to sensible results is when the called
function is internally implemented using a closure via some other
package again.
Having thought about this one a bit, it seems what's required is to
split collecting the callstack information, from creating the message.
Collect the information in one function call, and pass it into the
other.
This would be useful in CPS for example. Because the closures used in
CPS::kseq or kpar aren't necessarily invoked during the dynamic scope of
the function that lexically contains the code, a call to croak may not
be able to infer the calling context. Even if they are, the presence of
stack frames in the CPS package would confuse croak's scanning of the
callstack. Instead, it would be better to capture the calling context
using whence, and pass it into whoops if required for generating a
message.
For example, this from IO::Async::Connector:
sub connect
{
my ( %params ) = @_;
...
my $where = whence;
kpar(
sub {
my ( $k ) = @_;
if( exists $params{host} and exists $params{service} ) {
my $on_resolve_error = $params{on_resolve_error} or whoops $where,
"Expected 'on_resolve_error' callback";
...
}
These functions would be a fairly simple replacement of carp and croak;
capture the callsite information at entry to a function, and pass it to
the message warning function.
It does occur to me though, the code will be small and self-contained,
and not specific to CPS. I think it ought to live in its own module
somewhere - any ideas on a name?
--
Paul "LeoNerd" Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
