Log::An...ackTrace(3)

🌸 NAME 🌸

Log::Any::Proxy::WithStackTrace β€” it's the Log::Any proxy that looks at your sad little string error and goes "bestie, no, you're an object now, and you brought receipts" (the receipts being a stack trace πŸ’…).

Okay and quick vibe check on the page itself: this is from the User Contributed Perl Documentation, manual section 3, and the page title is literally rendered as Log::An...ackTrace(3) because some terminal said "we have Log::Any::Proxy::WithStackTrace(3) at home" and truncated the icon. iykyk. 🫢


✨ VERSION ✨

version 1.718 β€” that's the one, fr fr. πŸŽ€


πŸ¦‹ SYNOPSIS πŸ¦‹

  use Log::Any qw( $log, proxy_class => 'WithStackTrace' );

  # Allow stack trace call stack arguments to be logged:
  use Log::Any qw( $log, proxy_class => 'WithStackTrace',
                         proxy_show_stack_trace_args => 1 );

  # Configure some adapter that knows how to:
  #  1) handle structured data, and
  #  2) handle message objects which have a "stack_trace" method:
  Log::Any::Adapter->set($adapter);

  $log->error("Help!");   # stack trace gets automatically added,
                          # starting from this line of code

πŸ’– DESCRIPTION πŸ’–

So here's the tea. Some log adapters β€” Log::Any::Adapter::Sentry::Raven, for example β€” absolutely thrive when you hand them message objects that already carry a stack trace. Main character behavior, love that for them. ✨

But if there's no stack trace available and some fallback logic has to generate one, that trace can come out confusing as hell 😭, because it starts relative to where the log adapter was called, not relative to where the logging method was originally called. Not the same place. Not even close. It's giving "who even called this".

With this proxy in place though? If any logging method gets called with a log message that's a non-reference scalar (i.e. a string), that message gets upgraded into a Log::Any::MessageWithStackTrace object that has a stack_trace method β€” and that method returns a trace relative to where the logging method was called. πŸ‘‘ And a string overload is provided on the object so it still returns your original log message. Ate.

Also, and this is the important part: any call stack arguments in the stack trace get deleted before logging, so you don't accidentally log sensitive data. Rude awakening avoided. πŸ™ˆ This happens both for message objects that were auto-generated from string messages and for message objects that were passed in directly (if they appear to have a stack trace method). And if you want to turn off that default argument-scrubbing behavior, you do it by specifying a true value for the proxy_show_stack_trace_args import flag.

Important: this proxy should be used with a Log::Any::Adapter that's configured to handle structured data. Otherwise the object created here just gets stringified before you can use it to access the stack trace, and the whole vibe collapses. πŸ’€

🌈 METHODS 🌈

πŸ“ maybe_upgrade_with_stack_trace

  @args = $self->maybe_upgrade_with_stack_trace(@args);

This is an internal-use method, so don't be weird about it. It takes a non-reference scalar message and converts it into a Log::Any::MessageWithStackTrace object with a stack_trace method. A string overload is provided to return the original message. 🫢

Stack trace args get scrubbed out in case they contain sensitive data β€” unless the proxy_show_stack_trace_args option has been set. Then they stay. Your call, bestie.

🧚 maybe_delete_stack_trace_args

  $self->maybe_delete_stack_trace_args($arg);

Another internal-use method. You hand it a single argument that is a reference, and it tries to figure out whether that argument is an object with a stack trace β€” and if so, it tries to delete any stack trace args. Detective energy. πŸ”

The logic is based on Devel::StackTrace::Extract.

It specifically looks for objects with a stack_trace method (which should catch anything that does StackTrace::Auto, including anything that does Throwable::Error), or a trace method (used by Exception::Class and Moose::Exception and friends).

And it specifically ignores Mojo::Exception objects, because their stack traces don't contain any call stack args. Not personal, just facts. πŸ’…

πŸŽ€ delete_args_from_stack_trace($trace)

  $self->delete_args_from_stack_trace($trace)

To scrub potentially sensitive data from Devel::StackTrace arguments, this method deletes arguments from all of the Devel::StackTrace::Frame in the trace. All of them. Every single frame. Clean sweep. ✨


πŸ‘‘ AUTHORS πŸ‘‘

  • Jonathan Swartz <swartz@pobox.com>
  • David Golden <dagolden@cpan.org>
  • Doug Bell <preaction@cpan.org>
  • Daniel Pittman <daniel@rimspace.net>
  • Stephen Thirlwall <sdt@cpan.org>

Legends, every one of them. 🌟


This software is copyright (c) 2017 by Jonathan Swartz, David Golden, and Doug Bell.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.


and that's the whole page, bestie 🫢 this little icon was documented by perl v5.42.0 on 2025-07-28, and the page we just read was Log::An...ackTrace(3) β€” say it with me, one more time for the people in the back πŸ’…βœ¨

πŸ“¦ where this page comes from