Have you talked to the maintainer of Carp about this? It might be best to just suggest it as a new feature in Carp itself.
Otherwise, Carp::Whence or something might seem reasonable to me. On Sat, Mar 5, 2011 at 4:11 AM, Paul LeoNerd Evans <leon...@leonerd.org.uk>wrote: > (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/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iD8DBQFNcihqvLS2TC8cBo0RAuSrAJ9omaYwINWa31kEAh3jQtgjI03sMACePZzP > VbxfM0a4TuhPoJijNBwu2eg= > =Fg2o > -----END PGP SIGNATURE----- > > -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
