Re: Disable Perl warning

In addition to what others have said:

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).
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]

When's the last time you used duct tape on a duct? --Larry Wall

Comment on Re: Disable Perl warning Download Code

Replies are listed 'Best First'.
Re^2: Disable Perl warning by davido (Cardinal) on Nov 26, 2012 at 17:35 UTC
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	[reply] [d/l] [select]
Re^3: Disable Perl warning by choroba (Cardinal) on Nov 27, 2012 at 10:37 UTC
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. لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ	[reply] [d/l]
Re^4: Disable Perl warning by tobyink (Canon) on Nov 27, 2012 at 10:53 UTC
Within the scope of `use strict qw(subs vars)` the `once` warning is about a hundred times more annoying than it is useful. `void` and `uninitialized` are also of questionable value, and although the idea of `numeric` warnings is good, the details are silly... `use feature qw(say); use warnings qw(numeric); my $foo = ""; say $foo+1; # why does this warn, my $bar = []; say $bar+1; # when this does not?` [download] `perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'`	[reply] [d/l] [select]