kgoess has asked for the wisdom of the Perl Monks concerning the following question:

I happened to be checking 'perldoc Carp' for Carp::longmess, which I've always used, and noticed the documentation is not there in the latest Perl. In fact the documentation was removed in 5.8.9 in commit d735c2e in a patch from Ben Tilly <ben_tilly@operamail.com> 2006-10-22 07:07:23.

Apparently he didn't like because the stack trace is off by one:

- Removed documentation of shortmess and longmess. Unfortunately longmess doesn't do anything particularly reasonable, and it can't be made to do so because of backwards compatibility with code that depended on the old behaviour. http://www.nntp.perl.org/group/perl.perl5.porters/2006/10/msg117394.html

Does anybody else find that "doesn't do anything particularly reasonable" little extreme? longmess() gives a perfectly good stacktrace up to your current method. He doesn't go so far as to deprecate it though, he just removed the pod. What are other people using to get a stacktrace as a string, these days then? 

$ perl test.pl
stacktrace leading to fourth at test.pl line 10
        main::third() called at test.pl line 7
        main::second() called at test.pl line 4
        main::first() called at test.pl line 16
dying in fourth at test.pl line 14
        main::fourth() called at test.pl line 10
        main::third() called at test.pl line 7
        main::second() called at test.pl line 4
        main::first() called at test.pl line 16
$ cat -n test.pl
     1  use Carp;
     2
     3  sub first {
     4          second();
     5  }
     6  sub second {
     7          third();
     8  }
     9  sub third {
    10          fourth();
    11  }
    12  sub fourth {
    13          print STDERR Carp::longmess('stacktrace leading to fou
+rth');
    14          Carp::confess("dying in fourth");
    15  }
    16  first();

[download]

Replies are listed 'Best First'.
Re: is Carp::longmess deprecated?
by kcott (Archbishop) on Nov 29, 2010 at 19:05 UTC

    I haven't needed to capture stacktrace information (as opposed to outputting it from confess or, rarely, cluck) for some years but I recall I generated custom stacktrace messages with caller.

    Looking at the 5.12.2 source code (http://cpansearch.perl.org/src/JESSE/perl-5.12.2/lib/Carp.pm), croak and confess are implemented via longmess (with carp and cluck via shortmess):

    sub croak   { die  shortmess @_ }
sub confess { die  longmess  @_ }
sub carp    { warn shortmess @_ }
sub cluck   { warn longmess  @_ }

    [download]

    There appears to be no change to that in the latest 5.13.7 development source (http://cpansearch.perl.org/src/BINGOS/perl-5.13.7/lib/Carp.pm), so no indication of deprecation at this point in time.

    Maybe someone with insider information can provide a more definite answer.

    -- Ken

[reply]
[d/l]
      I recall I generated custom stacktrace messages with caller.
      Yeah, I could do a loop around caller() too, but it seems a shame to if there's a core module that already does the same thing.
[reply]
[d/l]

        I agree with not reinventing the wheel. My reference to caller() was really just in response to your question about what other people were using. I can't remember the details but do recall I needed the information in some sort of custom format and caller() was quite appropriate for that. If I wanted to capture the same information that is output by confess(), I would probably use longmess().

        -- Ken

[reply]
[d/l]
[select]
Re: is Carp::longmess deprecated?
by jettero (Monsignor) on Nov 29, 2010 at 18:20 UTC
    I'm no expert, but I believe that's what cluck is for. I think the idea is to just offer those four methods... carp cluck croak confess.
[reply]
      Yeah, but I don't want the stacktrace on stderr, I want the string.
[reply]
Re: is Carp::longmess deprecated?
by tilly (Archbishop) on Jan 18, 2011 at 23:10 UTC
    YMMV, but when I see a stack backtrace, I expect it to show me what line triggered that stack backtrace. Otherwise it isn't very useful for me.

    longmess does not do that, and can't for backwards compatibility reasons.

[reply]
      On further thought, it seems to me that my "mileage" does indeed vary. Rather I have a different notion of what the backtrace "trigger" is. In my case, the longmess call occurs in a "utility" routine referred to in $SIG{__DIE__} or $SIG{__WARN__} . I suspect that is a very common, or perhaps even typical usage. I don't want my error report to the user to mention the utility routine as it is not in fact the "trigger" of interest and in fact could be confusing. By omitting this information, longmess is doing exactly what I want. If the information about the utility routine is indeed of interest, it can be added to the message. That's what longmess is all about - letting you tailor the content, format, and destination of the trace message.

      So I think the longmess design does indeed make sense. And, as I mentioned in my previous (Anonymous) comment, would be repairable if it didn't. So please restore the documentation of this function, and get it out of this quasi-deprecated limbo.

      Thanks, -LenW

[reply]
      Would it be possible for correct behavior to be controlled by a non-default value of a variable? Wouldn't that make it backwards compatible? If that were done, could longmess be documented again? It makes me nervous to use an undocumented feature that "so far" is still available. -LenW
[reply]

Back to Seekers of Perl Wisdom