In long heres a copy of the section "Whats wrong with -w and $^W" from perllexwarn
Although very useful, the big problem with using -w on the command line to enable warnings is that it is all or nothing. Take the typical scenario when you are writing a Perl program. Parts of the code you will write yourself, but it's very likely that you will make use of pre-written Perl modules. If you use the -w flag in this case, you end up enabling warnings in pieces of code that you haven't written.
Similarly, using $^W to either disable or enable blocks of code is fundamentally flawed. For a start, say you want to disable warnings in a block of code. You might expect this to be enough to do the trick:
{
local ($^W) = 0 ;
my $a =+ 2 ;
my $b ; chop $b ;
}
When this code is run with the -w flag, a warning will be produced for the $a line -- "Reversed += operator".
The problem is that Perl has both compile-time and run-time warnings. To disable compile-time warnings you need to rewrite the code like this:
{
BEGIN { $^W = 0 }
my $a =+ 2 ;
my $b ; chop $b ;
}
The other big problem with $^W is the way you can inadvertently change the warning setting in unexpected places in your code. For example, when the code below is run (without the -w flag), the second call to doit will trip a "Use of uninitialized value" warning, whereas the first will not.
sub doit
{
my $b ; chop $b ;
}
doit() ;
{
local ($^W) = 1 ;
doit()
}
This is a side-effect of $^W being dynamically scoped.
Lexical warnings get around these limitations by allowing finer control over where warnings can or can't be tripped.
Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.
In reply to Re: ... powerful?
by demerphq
in thread #!/usr/bin/perl -w
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |