Re: Why use warnings? -w

[davido]

To clarify, the "Use of uninitialized value in..." warning is a runtime warning, not a compilation error, and it is not fatal by default. It is often useful because it alerts the developer to the fact that he or she is doing something with a variable that appears to be expecting it to contain a defined value, which it does not have. For example, consider the following code:

use warnings;                                                         
+           
                                                                      
+           
while (defined(my $line = <DATA>)) {                                  
+           
    print "\n";                                                       
+           
    chomp($line);                                                     
+           
    my ($k, $v) = split /\s*=\s*/, $line;                             
+           
    print "The $k key has $v value\n";                                
+           
    output_flush();                                                   
+           
}                                                                     
+           
                                                                      
+           
sub output_flush {                                                    
+           
    # Keep our STDOUT and STDERR in sync with each other, and in itera
+tion order:
    $_->flush for *STDERR, *STDOUT;                                   
+           
}                                                                     
+           
                                                                      
+           
__DATA__                                                              
+           
[main]                                                                
+           
foo=bar                                                               
+           
baz=buzz                                                              
+           
                                                                      
+           
[config]                                                              
+           
bingo=42

The output will be as follows:

Use of uninitialized value $v in concatenation (.) or string at mytest
+.pl line 12, <DATA> line 1.
The [main] key has  value

The foo key has bar value

The baz key has buzz value

Use of uninitialized value $k in concatenation (.) or string at mytest
+.pl line 12, <DATA> line 4.
Use of uninitialized value $v in concatenation (.) or string at mytest
+.pl line 12, <DATA> line 4.
The  key has  value

Use of uninitialized value $v in concatenation (.) or string at mytest
+.pl line 12, <DATA> line 5.
The [config] key has  value

The bingo key has 42 value

Why?

On the first iteration the line read in is [main], which we try to split on '=', allowing for some whitespace. Since there is no = character, only the $k variable receives data, and $v remains undefined. This happens on two occasions through this example run. So here the warnings alert us that we're not gracefully handling lines that contain section headers ([main] and [config]). This is useful to know, because we might be doing something with this data that would lead to corruption in our results.

On another line we see "The key has value", preceded by a couple of warnings. Those warnings came because we didn't gracefully handle a blank line. So again the warnings have now alerted us to something we should be better anticipating and dealing with, which could be skewing or corrupting our results.

This is a pretty trivial example, but it's a common class of bugs. The purpose of the uninitialized warning is to let us know we are acting upon a variable as though we expect it to have a defined value, and instead it's value is undef. This may be fine, or may be a mistake. Imagine how much harder it would be to spot if $v contained a number, or undef, and that number were used in an equation that obscured the fact that it came in undefined.

The undefined warning is at least smart enough to not complain when you do something like this:

my $c;
while ($c++ < 10) {
    print "$c\n";
}

Here $c starts out undef, but is postincremented during the first comparison. And in fact, there are two warnings that are suppressed automatically in this example; the first is an uninitialized warning for numeric comparison. The second is uninitialized for the numerical addition (postincrement). Perl lets you do both of those in THIS context because they're a common idiom and usually not incorrect. However, in other cases where the intent isn't so clear Perl would complain about the relational comparison, and $c = $c + 1 would probably also warn.

A full explanation of the purposes of strict and warnings is really more than I should be typing into a response here when there's good documentation already available. But the short and sweet explanation is that these are tools to help you discover bugs, and to make development work easier. They're not always useful, and can be turned off selectively if ever they get in the way of legitimate work.

For additional information, see the following docs:

strict, warnings, perllexwarn, perldata.

There certainly are other documents in Perl's POD, but these will get you started, and will link to additional reading. In the end, yes, you can ignore warnings, and can even disable them or disable strictures, but for nontrivial code, doing so will probably increase development and debugging time, and may leave you with latent bugs you would have otherwise discovered quickly.