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 keyword 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 points up to its call.
To track down weird warnings or exceptions throughout your system, enable Carp's verbose mode throughout the entire program:
This changes all croak() calls to produce confess()'s behavior and all carp() calls to cluck()'s behavior.
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. The presence of use warnings; or an equivalentSuch as use Modern::Perl; in code indicates that the authors intended that normal operation of the code 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 in which Perl may find 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. (Alternately see 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 variable 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 (in this case, Scary::Monkey). Users can enable it explicitly with use warnings 'Scary::Monkey' or disable it explicitly with no warnings 'Scary::Monkey'. To report a warning, use the warnings::warn() function in conjunction with warnings::enabled():
If warnings::enabled() is true, then the calling lexical scope has this warning enabled. You can also report warnings for an existing warnings category, such as the use of deprecated constructs:
The warnings::warnif() function checks the named warnings category and reports the error if it's active.
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 138:
-
A non-empty Z<>
- Around line 198:
-
A non-empty Z<>