1. Your production code should not produce warnings. Generally speaking, if you have warnings, something is not right. Rather than trying to silence the warnings, you should heed what they say and fix the problem. Occasionally, in very rare cases, a certain command may cause a warning that is spurious but unavoidable. In that case, you can enclose just the offending command in a lexical block and silence the warnings there only (see below for example).
   
   
2. You can redirect warnings so they aren't displayed to the user. It is understandable if you don't want the end user to see warnings or errors that your code produces. However, the better solution is to redirect warnings to where the user can't see them. That way, you still have access to them for debugging purposes if something goes wrong. See open for an example of redirecting STDERR to a file. If yours is a CGI program, CGI::Carp gives you flexible options for this. (And in a CGI program, warnings are not seen by the user anyway unless someone has explicitly directed them to the user).

Example: Disabling warnings for a single command.

{
   no warnings; #Disable warnings for this block only

   spurious_warning_command();
}
[download]

Occasionally, in very rare cases, a certain command may cause a warning that is spurious but unavoidable. In that case, you can enclose just the offending command in a lexical block and silence the warnings there only...

.

This is a necessary evil. While 99% of the time it's possible to, without jumping through coding hoops, code in such a way that produces no warnings, there is the 1% where the warning comes with the simplest use case:

use strict;
use warnings;

use List::Util qw( reduce );

print factorial(5), "\n";

sub factorial {
  return reduce { $a * $b } 1 .. $_[0] || 1;
}
__END__
__OUTPUT__
Name "main::a" used only once: possible typo at mytest.pl line 10.
Name "main::b" used only once: possible typo at mytest.pl line 10.
120
[download]

The only reasonable way to squelch that pair of warnings is to put "no warnings;" inside reduce's code block, and yet we're not doing anything even mildly devious.




Dave

The only reasonable way to squelch that pair of warnings is to put "no warnings;" inside reduce's code block

Well, the other reasonable way is to put no warnings 'once'; into the block.
لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

Probably not the best way, but you could check which server you are on and then do:

unless ($main_server) {
    use warnings;
}
[download]

Edit: As pointed out below, definitely not the way to do it!

The warnings pragma is lexical, and somehow it seems inelegant to wrap an entire file's code in an unless statement. Probably a cleaner approach would be the if pragma:

use if ! $MODE eq 'PRODUCTION', warnings;
[download]

Personally I think I would prefer figuring out why there are warnings being generated in the first place, fix those that need fixing, and for the rest...

{ 
  no warnings 'warning type'; 
  # Code that generated the useless warning here 
}
[download]

...but I do understand that there are times when enough thought has been put into it, nobody who understands the warning would see them anyway, and ultimately it's just time to silence them all and move on.




Dave

Note that use warnings is limited to the lexical block it it present in:

if (1) {
    use warnings;
}

# no warnings
say "Yup" if "zero" == 0;
[download]