Back to Top

Friday, May 09, 2008

My Perl blog - how to turn off warnings

There seems to be a meme going around which encourages blogging about Perl. So here is my contribution:

When you write scripts, it is really, really recommended to use the strict and warning pragmas (eventually diagnostics):

use strict;
use warnings;
use diagnostics; #mainly for debugging, to better understand the messages

I can't tell you how many times this saved my behind. However in very rare cases it is necessary to turn some warnings off. For example I was writing some benchmarks for BK Trees, and almost instantly got the Deep recursion on subroutine. Because I decided that I know what I'm doing (and because I was too lazy to rewrite it in a less elegant iterative fashion) I simply said:

no warnings 'recursion';

I found the solution by searching for the error message, however I became curious: how can I find out what the disable-keyword for a given type of warning is?

I just recently found the answer: the core warnings are described in the perldiag page. (If you have perl installed, you can use the perldoc perldiag to read it locally.) To find out what the warning means and/or how you can disable it, search for the partial error message (because it can contain dynamically generated parts. Here is an example:

%s package attribute may clash with future reserved word: %s

(W reserved) A lowercase attribute name was used that had a package-specific handler. That name might have a meaning to Perl itself some day, even though it doesn’t yet. Perhaps you should use a mixed-case attribute name, instead. See attributes.

First is the error/warning message. The W means that this is a warning, and the word after it is the disable keyword, meaning that if you want to disable the given warning, you have to give that word between quotes. In this case it would be:

no warnings 'reserved';

Warnings (like many other constructs) are lexically scopeable, meaning that they are enabled / disabled only in the current lexical context (package, codeblock, subrutine, etc). A good practice is to disable warnings in the smallest lexical context possible (to benefit from them if a mistake is made elsewhere).

To learn even more about the warnings in Perl, you can read the following documentation:

2 comments:

  1. THANK YOU for that - now I can finally get those uninitialized variable warnings out of my application logs. Have a beer on me ;-)

    ReplyDelete
  2. Anonymous12:45 AM

    heh... mostly, on Eclipse with Epic, where a turn off such warnings is non existent. Thanks.

    ReplyDelete