Re^4: use warnings and debug messages

IMHO what you suggested can be achieved by

use warnings;
no warnings "uninitialized";
[download]

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;
}
[download]

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.

Comment on Re^4: use warnings and debug messages Select or Download Code

Replies are listed 'Best First'.
Re^5: use warnings and debug messages ( caller(expr) ) by LanX (Saint) 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!}	[reply] [d/l] [select]
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.	[reply]

update