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