Perl 5 produces optional warnings for many confusing, unclear, and ambiguous situations. Even though you should almost always enable warnings unconditionally, certain circumstances dictate prudence in disabling certain warnings--and Perl supports this.
Use the warn builtin to emit a warning:
warn prints a list of values to the STDERR filehandle (filehandle). Perl will append the filename and line number on which the warn call occurred unless the last element of the list ends in a newline.
The core Carp module offers other mechanisms to produce warnings. Its carp() function reports a warning from the perspective of the calling code. That is, you could check the arity of a function (arity) with:
... and anyone who reads the error message will receive the filename and line number of the calling code, not only_two_arguments(). Similarly, Carp's cluck() produces an entire backtrace of all function calls up to the current function.
To track down weird warnings or exceptions throughout your system, enable Carp's verbose mode throughout the entire program:
This changes all carp() (and croak()--reporting_errors) calls to include a backtrace. When you organize your code into modules (modules), use Carp instead of warn or die to save debugging time.
Lexical encapsulation of warnings is as important as lexical encapsulation of variables. Older code may use the -w command-line argument to enable warnings throughout the program, even if other code has not specifically attempted to suppress warnings. It's all or nothing. If you have the wherewithal to eliminate warnings and potential warnings throughout the entire codebase, this can be useful.
The modern approach is to use the warnings pragma...or an equivalent such as use Modern::Perl;., which indicates the intent of the author of the code that normal operation should not produce warnings.
All of -w, -W, and -X affect the value of the global variable $^W. Code written before the warnings pragma (Perl 5.6.0 in spring 2000) may localize $^W to suppress certain warnings within a given scope. New code should use the pragma instead.
To disable selective warnings within a scope, use no warnings; with an argument list. Omitting the argument list disables all warnings within that scope.
perldoc perllexwarn lists all of the warnings categories your version of Perl 5 understands with the warnings pragma. Most of them represent truly interesting conditions which Perl may find in your program. A few may be unhelpful in specific conditions. For example, the recursion warning will occur if Perl detects that a function has called itself more than a hundred times. If you are confident in your ability to write recursion-ending conditions, you may disable this warning within the scope of the recursion (though tail calls may be better; tail_calls).
If you're generating code (code_generation) or locally redefining symbols, you may wish to disable the redefine warnings.
Some experienced Perl hackers disable the uninitialized value warnings in string-processing code which concatenates values from many sources. Careful initialization of variables can avoid the need to disable the warning, but local style and concision may render this warning moot.
If your project considers warnings as onerous as errors, you can make them lexically fatal. To promote all warnings into exceptions:
You may also make specific categories of warnings fatal, such as the use of deprecated constructs:
Just as you can catch exceptions, so you can catch warnings. The %SIG variableSee perldoc perlvar. holds handlers for all sorts of signals Perl or your operating system might throw. It also includes two slots for signal handlers for Perl 5 exceptions and warnings. To catch a warning, install an anonymous function into $SIG{__WARN__}:
Within the warning handler, the first argument is the warning's message. Admittedly, this technique is less useful than disabling warnings lexically--but it can come to good use in test modules such as Test::Warnings from the CPAN, where the actual text of the warning is important.
With the use of the warnings::register pragma you can even create your own lexical warnings so that users of your code can enable and disable lexical warnings as appropriate. This is easy to accomplish; from a module, use the warnings::register pragma:
This will create a new warnings category named after the package Scary::Monkey. Enable these warnings with use warnings 'Scary::Monkey' and disable them with no warnings 'Scary::Monkey'.
Use warnings::enabled() to test if the calling lexical scope has the given warning category enabled. Use warnings::warnif() to produce a warning only if warnings are in effect. For example, to produce a warning in the deprecated category:
See perldoc perllexwarn for more details.
Hey! The above document had some coding errors, which are explained below:
- Around line 3:
-
A non-empty Z<>
- Around line 12:
-
A non-empty Z<>
- Around line 86:
-
Deleting unknown formatting code N<>
- Around line 137:
-
A non-empty Z<>
- Around line 163:
-
Deleting unknown formatting code N<>
- Around line 191:
-
A non-empty Z<>