http://www.perlmonks.org?node_id=1183878


in reply to Re^3: use warnings and debug messages
in thread use warnings and debug messages

IMHO what you suggested can be achieved by
use warnings; no warnings "uninitialized";
but actually this gave me an idea to use __WARN__ and caller() to check if the warning happened on a line with a debug call and hide those.
use 5.010; use strict; use warnings; my $x = 42; my $y; $SIG{__WARN__} = sub { my $warn = shift; my ($package, $filename, $line) = caller; if (open my $fh, '<', $filename) { my @lines = <$fh>; return if $lines[$line-1] =~ /debug\(/; } print $warn; }; my $z = $x+$y; debug("x=$x y=$y"); sub debug { say shift; }
Though this will have a runtime impact we need to consider. Of course then we could cache the filename/rownumber pairs to reduce the cost. Thank you for the suggestion.

Replies are listed 'Best First'.
Re^5: use warnings and debug messages ( caller(expr) )
by LanX (Cardinal) on Mar 08, 2017 at 01:50 UTC
    Hi Gabor

    > a runtime impact we need to consider

    No need to read the source lines from file.

    caller(EXPR) gives you the subs name already as 4th return value.

    See caller for details.

    update

    never mind, I just realized that you still want to parse the code where the call happens, because the error happens in the args-list there debug("x=$x y=$y");

    That's pretty much as stable as a source filter.

    Why not relying on Smart::Comments then?

    YMMV

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Je suis Charlie!

Re^5: use warnings and debug messages
by stevieb (Canon) on Mar 08, 2017 at 00:52 UTC

    Hey Gabor,

    "IMHO what you suggested can be achieved by ..."

    Indeed, that's why I explicitly said "or do something else with", which I was sure you'd want to do, while allowing my example to be as concise as possible. Emphasis added:

    "Perhaps write a sig handler for warn, and evaporate (or do something else with) all uninit warnings?"

    I'm glad it moved you toward something you can work with, but you're definitely right... it's going to add a lot of extra cycles. If this is prod-type code, perhaps a refactor as others have suggested is in order.