- publishing free software manuals
Perl Language Reference Manual
by Larry Wall and others
Paperback (6"x9"), 724 pages
ISBN 9781906966027
RRP £29.95 ($39.95)

Sales of this book support The Perl Foundation! Get a printed copy>>>

24.2 What's wrong with -w and $^W

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.

ISBN 9781906966027Perl Language Reference ManualSee the print edition