1 | =head1 NAME
|
---|
2 | X<warning, lexical> X<warnings> X<warning>
|
---|
3 |
|
---|
4 | perllexwarn - Perl Lexical Warnings
|
---|
5 |
|
---|
6 | =head1 DESCRIPTION
|
---|
7 |
|
---|
8 | The C<use warnings> pragma is a replacement for both the command line
|
---|
9 | flag B<-w> and the equivalent Perl variable, C<$^W>.
|
---|
10 |
|
---|
11 | The pragma works just like the existing "strict" pragma.
|
---|
12 | This means that the scope of the warning pragma is limited to the
|
---|
13 | enclosing block. It also means that the pragma setting will not
|
---|
14 | leak across files (via C<use>, C<require> or C<do>). This allows
|
---|
15 | authors to independently define the degree of warning checks that will
|
---|
16 | be applied to their module.
|
---|
17 |
|
---|
18 | By default, optional warnings are disabled, so any legacy code that
|
---|
19 | doesn't attempt to control the warnings will work unchanged.
|
---|
20 |
|
---|
21 | All warnings are enabled in a block by either of these:
|
---|
22 |
|
---|
23 | use warnings;
|
---|
24 | use warnings 'all';
|
---|
25 |
|
---|
26 | Similarly all warnings are disabled in a block by either of these:
|
---|
27 |
|
---|
28 | no warnings;
|
---|
29 | no warnings 'all';
|
---|
30 |
|
---|
31 | For example, consider the code below:
|
---|
32 |
|
---|
33 | use warnings;
|
---|
34 | my @a;
|
---|
35 | {
|
---|
36 | no warnings;
|
---|
37 | my $b = @a[0];
|
---|
38 | }
|
---|
39 | my $c = @a[0];
|
---|
40 |
|
---|
41 | The code in the enclosing block has warnings enabled, but the inner
|
---|
42 | block has them disabled. In this case that means the assignment to the
|
---|
43 | scalar C<$c> will trip the C<"Scalar value @a[0] better written as $a[0]">
|
---|
44 | warning, but the assignment to the scalar C<$b> will not.
|
---|
45 |
|
---|
46 | =head2 Default Warnings and Optional Warnings
|
---|
47 |
|
---|
48 | Before the introduction of lexical warnings, Perl had two classes of
|
---|
49 | warnings: mandatory and optional.
|
---|
50 |
|
---|
51 | As its name suggests, if your code tripped a mandatory warning, you
|
---|
52 | would get a warning whether you wanted it or not.
|
---|
53 | For example, the code below would always produce an C<"isn't numeric">
|
---|
54 | warning about the "2:".
|
---|
55 |
|
---|
56 | my $a = "2:" + 3;
|
---|
57 |
|
---|
58 | With the introduction of lexical warnings, mandatory warnings now become
|
---|
59 | I<default> warnings. The difference is that although the previously
|
---|
60 | mandatory warnings are still enabled by default, they can then be
|
---|
61 | subsequently enabled or disabled with the lexical warning pragma. For
|
---|
62 | example, in the code below, an C<"isn't numeric"> warning will only
|
---|
63 | be reported for the C<$a> variable.
|
---|
64 |
|
---|
65 | my $a = "2:" + 3;
|
---|
66 | no warnings;
|
---|
67 | my $b = "2:" + 3;
|
---|
68 |
|
---|
69 | Note that neither the B<-w> flag or the C<$^W> can be used to
|
---|
70 | disable/enable default warnings. They are still mandatory in this case.
|
---|
71 |
|
---|
72 | =head2 What's wrong with B<-w> and C<$^W>
|
---|
73 |
|
---|
74 | Although very useful, the big problem with using B<-w> on the command
|
---|
75 | line to enable warnings is that it is all or nothing. Take the typical
|
---|
76 | scenario when you are writing a Perl program. Parts of the code you
|
---|
77 | will write yourself, but it's very likely that you will make use of
|
---|
78 | pre-written Perl modules. If you use the B<-w> flag in this case, you
|
---|
79 | end up enabling warnings in pieces of code that you haven't written.
|
---|
80 |
|
---|
81 | Similarly, using C<$^W> to either disable or enable blocks of code is
|
---|
82 | fundamentally flawed. For a start, say you want to disable warnings in
|
---|
83 | a block of code. You might expect this to be enough to do the trick:
|
---|
84 |
|
---|
85 | {
|
---|
86 | local ($^W) = 0;
|
---|
87 | my $a =+ 2;
|
---|
88 | my $b; chop $b;
|
---|
89 | }
|
---|
90 |
|
---|
91 | When this code is run with the B<-w> flag, a warning will be produced
|
---|
92 | for the C<$a> line -- C<"Reversed += operator">.
|
---|
93 |
|
---|
94 | The problem is that Perl has both compile-time and run-time warnings. To
|
---|
95 | disable compile-time warnings you need to rewrite the code like this:
|
---|
96 |
|
---|
97 | {
|
---|
98 | BEGIN { $^W = 0 }
|
---|
99 | my $a =+ 2;
|
---|
100 | my $b; chop $b;
|
---|
101 | }
|
---|
102 |
|
---|
103 | The other big problem with C<$^W> is the way you can inadvertently
|
---|
104 | change the warning setting in unexpected places in your code. For example,
|
---|
105 | when the code below is run (without the B<-w> flag), the second call
|
---|
106 | to C<doit> will trip a C<"Use of uninitialized value"> warning, whereas
|
---|
107 | the first will not.
|
---|
108 |
|
---|
109 | sub doit
|
---|
110 | {
|
---|
111 | my $b; chop $b;
|
---|
112 | }
|
---|
113 |
|
---|
114 | doit();
|
---|
115 |
|
---|
116 | {
|
---|
117 | local ($^W) = 1;
|
---|
118 | doit()
|
---|
119 | }
|
---|
120 |
|
---|
121 | This is a side-effect of C<$^W> being dynamically scoped.
|
---|
122 |
|
---|
123 | Lexical warnings get around these limitations by allowing finer control
|
---|
124 | over where warnings can or can't be tripped.
|
---|
125 |
|
---|
126 | =head2 Controlling Warnings from the Command Line
|
---|
127 |
|
---|
128 | There are three Command Line flags that can be used to control when
|
---|
129 | warnings are (or aren't) produced:
|
---|
130 |
|
---|
131 | =over 5
|
---|
132 |
|
---|
133 | =item B<-w>
|
---|
134 | X<-w>
|
---|
135 |
|
---|
136 | This is the existing flag. If the lexical warnings pragma is B<not>
|
---|
137 | used in any of you code, or any of the modules that you use, this flag
|
---|
138 | will enable warnings everywhere. See L<Backward Compatibility> for
|
---|
139 | details of how this flag interacts with lexical warnings.
|
---|
140 |
|
---|
141 | =item B<-W>
|
---|
142 | X<-W>
|
---|
143 |
|
---|
144 | If the B<-W> flag is used on the command line, it will enable all warnings
|
---|
145 | throughout the program regardless of whether warnings were disabled
|
---|
146 | locally using C<no warnings> or C<$^W =0>. This includes all files that get
|
---|
147 | included via C<use>, C<require> or C<do>.
|
---|
148 | Think of it as the Perl equivalent of the "lint" command.
|
---|
149 |
|
---|
150 | =item B<-X>
|
---|
151 | X<-X>
|
---|
152 |
|
---|
153 | Does the exact opposite to the B<-W> flag, i.e. it disables all warnings.
|
---|
154 |
|
---|
155 | =back
|
---|
156 |
|
---|
157 | =head2 Backward Compatibility
|
---|
158 |
|
---|
159 | If you are used with working with a version of Perl prior to the
|
---|
160 | introduction of lexically scoped warnings, or have code that uses both
|
---|
161 | lexical warnings and C<$^W>, this section will describe how they interact.
|
---|
162 |
|
---|
163 | How Lexical Warnings interact with B<-w>/C<$^W>:
|
---|
164 |
|
---|
165 | =over 5
|
---|
166 |
|
---|
167 | =item 1.
|
---|
168 |
|
---|
169 | If none of the three command line flags (B<-w>, B<-W> or B<-X>) that
|
---|
170 | control warnings is used and neither C<$^W> or the C<warnings> pragma
|
---|
171 | are used, then default warnings will be enabled and optional warnings
|
---|
172 | disabled.
|
---|
173 | This means that legacy code that doesn't attempt to control the warnings
|
---|
174 | will work unchanged.
|
---|
175 |
|
---|
176 | =item 2.
|
---|
177 |
|
---|
178 | The B<-w> flag just sets the global C<$^W> variable as in 5.005 -- this
|
---|
179 | means that any legacy code that currently relies on manipulating C<$^W>
|
---|
180 | to control warning behavior will still work as is.
|
---|
181 |
|
---|
182 | =item 3.
|
---|
183 |
|
---|
184 | Apart from now being a boolean, the C<$^W> variable operates in exactly
|
---|
185 | the same horrible uncontrolled global way, except that it cannot
|
---|
186 | disable/enable default warnings.
|
---|
187 |
|
---|
188 | =item 4.
|
---|
189 |
|
---|
190 | If a piece of code is under the control of the C<warnings> pragma,
|
---|
191 | both the C<$^W> variable and the B<-w> flag will be ignored for the
|
---|
192 | scope of the lexical warning.
|
---|
193 |
|
---|
194 | =item 5.
|
---|
195 |
|
---|
196 | The only way to override a lexical warnings setting is with the B<-W>
|
---|
197 | or B<-X> command line flags.
|
---|
198 |
|
---|
199 | =back
|
---|
200 |
|
---|
201 | The combined effect of 3 & 4 is that it will allow code which uses
|
---|
202 | the C<warnings> pragma to control the warning behavior of $^W-type
|
---|
203 | code (using a C<local $^W=0>) if it really wants to, but not vice-versa.
|
---|
204 |
|
---|
205 | =head2 Category Hierarchy
|
---|
206 | X<warning, categories>
|
---|
207 |
|
---|
208 | A hierarchy of "categories" have been defined to allow groups of warnings
|
---|
209 | to be enabled/disabled in isolation.
|
---|
210 |
|
---|
211 | The current hierarchy is:
|
---|
212 |
|
---|
213 | all -+
|
---|
214 | |
|
---|
215 | +- closure
|
---|
216 | |
|
---|
217 | +- deprecated
|
---|
218 | |
|
---|
219 | +- exiting
|
---|
220 | |
|
---|
221 | +- glob
|
---|
222 | |
|
---|
223 | +- io -----------+
|
---|
224 | | |
|
---|
225 | | +- closed
|
---|
226 | | |
|
---|
227 | | +- exec
|
---|
228 | | |
|
---|
229 | | +- layer
|
---|
230 | | |
|
---|
231 | | +- newline
|
---|
232 | | |
|
---|
233 | | +- pipe
|
---|
234 | | |
|
---|
235 | | +- unopened
|
---|
236 | |
|
---|
237 | +- misc
|
---|
238 | |
|
---|
239 | +- numeric
|
---|
240 | |
|
---|
241 | +- once
|
---|
242 | |
|
---|
243 | +- overflow
|
---|
244 | |
|
---|
245 | +- pack
|
---|
246 | |
|
---|
247 | +- portable
|
---|
248 | |
|
---|
249 | +- recursion
|
---|
250 | |
|
---|
251 | +- redefine
|
---|
252 | |
|
---|
253 | +- regexp
|
---|
254 | |
|
---|
255 | +- severe -------+
|
---|
256 | | |
|
---|
257 | | +- debugging
|
---|
258 | | |
|
---|
259 | | +- inplace
|
---|
260 | | |
|
---|
261 | | +- internal
|
---|
262 | | |
|
---|
263 | | +- malloc
|
---|
264 | |
|
---|
265 | +- signal
|
---|
266 | |
|
---|
267 | +- substr
|
---|
268 | |
|
---|
269 | +- syntax -------+
|
---|
270 | | |
|
---|
271 | | +- ambiguous
|
---|
272 | | |
|
---|
273 | | +- bareword
|
---|
274 | | |
|
---|
275 | | +- digit
|
---|
276 | | |
|
---|
277 | | +- parenthesis
|
---|
278 | | |
|
---|
279 | | +- precedence
|
---|
280 | | |
|
---|
281 | | +- printf
|
---|
282 | | |
|
---|
283 | | +- prototype
|
---|
284 | | |
|
---|
285 | | +- qw
|
---|
286 | | |
|
---|
287 | | +- reserved
|
---|
288 | | |
|
---|
289 | | +- semicolon
|
---|
290 | |
|
---|
291 | +- taint
|
---|
292 | |
|
---|
293 | +- threads
|
---|
294 | |
|
---|
295 | +- uninitialized
|
---|
296 | |
|
---|
297 | +- unpack
|
---|
298 | |
|
---|
299 | +- untie
|
---|
300 | |
|
---|
301 | +- utf8
|
---|
302 | |
|
---|
303 | +- void
|
---|
304 | |
|
---|
305 | +- y2k
|
---|
306 |
|
---|
307 | Just like the "strict" pragma any of these categories can be combined
|
---|
308 |
|
---|
309 | use warnings qw(void redefine);
|
---|
310 | no warnings qw(io syntax untie);
|
---|
311 |
|
---|
312 | Also like the "strict" pragma, if there is more than one instance of the
|
---|
313 | C<warnings> pragma in a given scope the cumulative effect is additive.
|
---|
314 |
|
---|
315 | use warnings qw(void); # only "void" warnings enabled
|
---|
316 | ...
|
---|
317 | use warnings qw(io); # only "void" & "io" warnings enabled
|
---|
318 | ...
|
---|
319 | no warnings qw(void); # only "io" warnings enabled
|
---|
320 |
|
---|
321 | To determine which category a specific warning has been assigned to see
|
---|
322 | L<perldiag>.
|
---|
323 |
|
---|
324 | Note: In Perl 5.6.1, the lexical warnings category "deprecated" was a
|
---|
325 | sub-category of the "syntax" category. It is now a top-level category
|
---|
326 | in its own right.
|
---|
327 |
|
---|
328 |
|
---|
329 | =head2 Fatal Warnings
|
---|
330 | X<warning, fatal>
|
---|
331 |
|
---|
332 | The presence of the word "FATAL" in the category list will escalate any
|
---|
333 | warnings detected from the categories specified in the lexical scope
|
---|
334 | into fatal errors. In the code below, the use of C<time>, C<length>
|
---|
335 | and C<join> can all produce a C<"Useless use of xxx in void context">
|
---|
336 | warning.
|
---|
337 |
|
---|
338 | use warnings;
|
---|
339 |
|
---|
340 | time;
|
---|
341 |
|
---|
342 | {
|
---|
343 | use warnings FATAL => qw(void);
|
---|
344 | length "abc";
|
---|
345 | }
|
---|
346 |
|
---|
347 | join "", 1,2,3;
|
---|
348 |
|
---|
349 | print "done\n";
|
---|
350 |
|
---|
351 | When run it produces this output
|
---|
352 |
|
---|
353 | Useless use of time in void context at fatal line 3.
|
---|
354 | Useless use of length in void context at fatal line 7.
|
---|
355 |
|
---|
356 | The scope where C<length> is used has escalated the C<void> warnings
|
---|
357 | category into a fatal error, so the program terminates immediately it
|
---|
358 | encounters the warning.
|
---|
359 |
|
---|
360 | To explicitly turn off a "FATAL" warning you just disable the warning
|
---|
361 | it is associated with. So, for example, to disable the "void" warning
|
---|
362 | in the example above, either of these will do the trick:
|
---|
363 |
|
---|
364 | no warnings qw(void);
|
---|
365 | no warnings FATAL => qw(void);
|
---|
366 |
|
---|
367 | If you want to downgrade a warning that has been escalated into a fatal
|
---|
368 | error back to a normal warning, you can use the "NONFATAL" keyword. For
|
---|
369 | example, the code below will promote all warnings into fatal errors,
|
---|
370 | except for those in the "syntax" category.
|
---|
371 |
|
---|
372 | use warnings FATAL => 'all', NONFATAL => 'syntax';
|
---|
373 |
|
---|
374 | =head2 Reporting Warnings from a Module
|
---|
375 | X<warning, reporting> X<warning, registering>
|
---|
376 |
|
---|
377 | The C<warnings> pragma provides a number of functions that are useful for
|
---|
378 | module authors. These are used when you want to report a module-specific
|
---|
379 | warning to a calling module has enabled warnings via the C<warnings>
|
---|
380 | pragma.
|
---|
381 |
|
---|
382 | Consider the module C<MyMod::Abc> below.
|
---|
383 |
|
---|
384 | package MyMod::Abc;
|
---|
385 |
|
---|
386 | use warnings::register;
|
---|
387 |
|
---|
388 | sub open {
|
---|
389 | my $path = shift;
|
---|
390 | if ($path !~ m#^/#) {
|
---|
391 | warnings::warn("changing relative path to /var/abc")
|
---|
392 | if warnings::enabled();
|
---|
393 | $path = "/var/abc/$path";
|
---|
394 | }
|
---|
395 | }
|
---|
396 |
|
---|
397 | 1;
|
---|
398 |
|
---|
399 | The call to C<warnings::register> will create a new warnings category
|
---|
400 | called "MyMod::abc", i.e. the new category name matches the current
|
---|
401 | package name. The C<open> function in the module will display a warning
|
---|
402 | message if it gets given a relative path as a parameter. This warnings
|
---|
403 | will only be displayed if the code that uses C<MyMod::Abc> has actually
|
---|
404 | enabled them with the C<warnings> pragma like below.
|
---|
405 |
|
---|
406 | use MyMod::Abc;
|
---|
407 | use warnings 'MyMod::Abc';
|
---|
408 | ...
|
---|
409 | abc::open("../fred.txt");
|
---|
410 |
|
---|
411 | It is also possible to test whether the pre-defined warnings categories are
|
---|
412 | set in the calling module with the C<warnings::enabled> function. Consider
|
---|
413 | this snippet of code:
|
---|
414 |
|
---|
415 | package MyMod::Abc;
|
---|
416 |
|
---|
417 | sub open {
|
---|
418 | warnings::warnif("deprecated",
|
---|
419 | "open is deprecated, use new instead");
|
---|
420 | new(@_);
|
---|
421 | }
|
---|
422 |
|
---|
423 | sub new
|
---|
424 | ...
|
---|
425 | 1;
|
---|
426 |
|
---|
427 | The function C<open> has been deprecated, so code has been included to
|
---|
428 | display a warning message whenever the calling module has (at least) the
|
---|
429 | "deprecated" warnings category enabled. Something like this, say.
|
---|
430 |
|
---|
431 | use warnings 'deprecated';
|
---|
432 | use MyMod::Abc;
|
---|
433 | ...
|
---|
434 | MyMod::Abc::open($filename);
|
---|
435 |
|
---|
436 | Either the C<warnings::warn> or C<warnings::warnif> function should be
|
---|
437 | used to actually display the warnings message. This is because they can
|
---|
438 | make use of the feature that allows warnings to be escalated into fatal
|
---|
439 | errors. So in this case
|
---|
440 |
|
---|
441 | use MyMod::Abc;
|
---|
442 | use warnings FATAL => 'MyMod::Abc';
|
---|
443 | ...
|
---|
444 | MyMod::Abc::open('../fred.txt');
|
---|
445 |
|
---|
446 | the C<warnings::warnif> function will detect this and die after
|
---|
447 | displaying the warning message.
|
---|
448 |
|
---|
449 | The three warnings functions, C<warnings::warn>, C<warnings::warnif>
|
---|
450 | and C<warnings::enabled> can optionally take an object reference in place
|
---|
451 | of a category name. In this case the functions will use the class name
|
---|
452 | of the object as the warnings category.
|
---|
453 |
|
---|
454 | Consider this example:
|
---|
455 |
|
---|
456 | package Original;
|
---|
457 |
|
---|
458 | no warnings;
|
---|
459 | use warnings::register;
|
---|
460 |
|
---|
461 | sub new
|
---|
462 | {
|
---|
463 | my $class = shift;
|
---|
464 | bless [], $class;
|
---|
465 | }
|
---|
466 |
|
---|
467 | sub check
|
---|
468 | {
|
---|
469 | my $self = shift;
|
---|
470 | my $value = shift;
|
---|
471 |
|
---|
472 | if ($value % 2 && warnings::enabled($self))
|
---|
473 | { warnings::warn($self, "Odd numbers are unsafe") }
|
---|
474 | }
|
---|
475 |
|
---|
476 | sub doit
|
---|
477 | {
|
---|
478 | my $self = shift;
|
---|
479 | my $value = shift;
|
---|
480 | $self->check($value);
|
---|
481 | # ...
|
---|
482 | }
|
---|
483 |
|
---|
484 | 1;
|
---|
485 |
|
---|
486 | package Derived;
|
---|
487 |
|
---|
488 | use warnings::register;
|
---|
489 | use Original;
|
---|
490 | our @ISA = qw( Original );
|
---|
491 | sub new
|
---|
492 | {
|
---|
493 | my $class = shift;
|
---|
494 | bless [], $class;
|
---|
495 | }
|
---|
496 |
|
---|
497 |
|
---|
498 | 1;
|
---|
499 |
|
---|
500 | The code below makes use of both modules, but it only enables warnings from
|
---|
501 | C<Derived>.
|
---|
502 |
|
---|
503 | use Original;
|
---|
504 | use Derived;
|
---|
505 | use warnings 'Derived';
|
---|
506 | my $a = new Original;
|
---|
507 | $a->doit(1);
|
---|
508 | my $b = new Derived;
|
---|
509 | $a->doit(1);
|
---|
510 |
|
---|
511 | When this code is run only the C<Derived> object, C<$b>, will generate
|
---|
512 | a warning.
|
---|
513 |
|
---|
514 | Odd numbers are unsafe at main.pl line 7
|
---|
515 |
|
---|
516 | Notice also that the warning is reported at the line where the object is first
|
---|
517 | used.
|
---|
518 |
|
---|
519 | =head1 TODO
|
---|
520 |
|
---|
521 | perl5db.pl
|
---|
522 | The debugger saves and restores C<$^W> at runtime. I haven't checked
|
---|
523 | whether the debugger will still work with the lexical warnings
|
---|
524 | patch applied.
|
---|
525 |
|
---|
526 | diagnostics.pm
|
---|
527 | I *think* I've got diagnostics to work with the lexical warnings
|
---|
528 | patch, but there were design decisions made in diagnostics to work
|
---|
529 | around the limitations of C<$^W>. Now that those limitations are gone,
|
---|
530 | the module should be revisited.
|
---|
531 |
|
---|
532 | document calling the warnings::* functions from XS
|
---|
533 |
|
---|
534 | =head1 SEE ALSO
|
---|
535 |
|
---|
536 | L<warnings>, L<perldiag>.
|
---|
537 |
|
---|
538 | =head1 AUTHOR
|
---|
539 |
|
---|
540 | Paul Marquess
|
---|