Re^2: use warnings and debug messages

[szabgab]

We have tons of these debug() calls and in most cases we don't care if the value is undef or the empty string.

We currently don't have "use warnings" in the code and turning them on will generate a lot of warnings that are useless to us making it hard to locate the important ones.

[ww]

Isn't "turning them on" a fairly cheap price of doing business?

Clearly, your problem case suggests that an option might be to "use warnings" after you've dealt with the more significant warnings errors/problems that are apt to turn up in new code... and even then, the price of going thru "tons" of code to check the then-new onslaught of warnings seems to me to be insignificant compared to the price of an error that gives away your product or that causes a client to suffer harm.

And one more thought:

• ...if the "uninitialized" warning is your real concern, it might suggest that some re-thinking the timing and manner of instantiating variables would be appropriate... to clean up what might be considered a code-smell.

If that seems too expensive, or the types of warnings are more diverse than you feel you can afford to deal with, perhaps its time to consider that the cost of selectively inserting "no warnings uninitialized" suggested by Vicar Eily is likely to be NO HIGHER and to pay the bonus of being clearer.

Edit: Strike/corrected language in para 1; fixed markup on "code smell" and fixed "that" to "than" in final para.

[stevieb]

So is your objective to be able to enable use warnings;?

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

use 5.010;
use strict;
use warnings;

$SIG{__WARN__} = sub {
    my $w = shift;
    if ($w !~ /uninitialized/){
        warn $w;
    }
};

my $x = 23;
my $y;

debug("x='$x' y='$y'");

sub debug { 
    say shift; 
}

[szabgab]

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.

[LanX]

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

[stevieb]

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.

[afoken]

We currently don't have "use warnings" in the code and turning them on will generate a lot of warnings that are useless to us

You know, these warnings are not there to make your life harder. It's not that perl takes your code as seed for a PRNG and then generates warnings from that PRNG. Every single warning generated has a reason, and most time, it is bad code or a possible error.

making it hard to locate the important ones.

If your code is such a mess, start by temporarily disabling the most frequent warnings - see warnings, or remove them by filtering STDERR, if you can't easily fix them.

Alexander

[LanX]

It should be possible to write your own Our::warnings pragma in order to activate only the finegrained warnings you want.

that's certainly better than using no warnings at all.

update

Something like

sub import { 
   my ($class, $date) = @_;

   ...
   warnings->import(@wanted_warnings);
   ...
}