Commit | Line | Data |
0453d815 |
1 | =head1 NAME |
2 | |
3 | perllexwarn - Perl Lexical Warnings |
4 | |
5 | =head1 DESCRIPTION |
6 | |
7 | The C<use warning> 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 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 warning ; |
23 | use warning 'all' ; |
24 | |
25 | Similarly all warnings are disabled in a block by either of these: |
26 | |
27 | no warning ; |
28 | no warning 'all' ; |
29 | |
30 | For example, consider the code below: |
31 | |
32 | use warning ; |
33 | my $a ; |
34 | my $b ; |
35 | { |
36 | no warning ; |
37 | $b = 2 if $a EQ 3 ; |
38 | } |
39 | $b = 1 if $a NE 3 ; |
40 | |
41 | The code in the enclosing block has warnings enabled, but the inner |
42 | block has them disabled. In this case that means that the use of the C<EQ> |
43 | operator won't trip a C<"Use of EQ is deprecated"> warning, but the use of |
44 | C<NE> will produce a C<"Use of NE is deprecated"> warning. |
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<"integer overflow"> |
54 | warning. |
55 | |
56 | my $a = oct "777777777777777777777777777777777777" ; |
57 | |
58 | |
59 | With the introduction of lexical warnings, mandatory warnings now become |
60 | I<default> warnings. The difference is that although the previously |
61 | mandatory warnings are still enabled by default, they can then be |
62 | subsequently enabled or disabled with the lexical warning pragma. For |
63 | example, in the code below, an C<"integer overflow"> warning will only |
64 | be reported for the C<$a> variable. |
65 | |
66 | my $a = oct "777777777777777777777777777777777777" ; |
67 | no warning ; |
68 | my $b = oct "777777777777777777777777777777777777" ; |
69 | |
70 | Note that neither the B<-w> flag or the C<$^W> can be used to |
71 | disable/enable default warnings. They are still mandatory in this case. |
72 | |
73 | =head2 What's wrong with B<-w> and C<$^W> |
74 | |
75 | Although very useful, the big problem with using B<-w> on the command |
76 | line to enable warnings is that it is all or nothing. Take the typical |
77 | scenario when you are writing a Perl program. Parts of the code you |
78 | will write yourself, but it's very likely that you will make use of |
79 | pre-written Perl modules. If you use the B<-w> flag in this case, you |
80 | end up enabling warnings in pieces of code that you haven't written. |
81 | |
82 | Similarly, using C<$^W> to either disable or enable blocks of code is |
83 | fundamentally flawed. For a start, say you want to disable warnings in |
84 | a block of code. You might expect this to be enough to do the trick: |
85 | |
86 | { |
87 | local ($^W) = 0 ; |
88 | my $a =+ 2 ; |
89 | my $b ; chop $b ; |
90 | } |
91 | |
92 | When this code is run with the B<-w> flag, a warning will be produced |
93 | for the C<$a> line -- C<"Reversed += operator">. |
94 | |
95 | The problem is that Perl has both compile-time and run-time warnings. To |
96 | disable compile-time warnings you need to rewrite the code like this: |
97 | |
98 | { |
99 | BEGIN { $^W = 0 } |
100 | my $a =+ 2 ; |
101 | my $b ; chop $b ; |
102 | } |
103 | |
104 | The other big problem with C<$^W> is that way you can inadvertently |
105 | change the warning setting in unexpected places in your code. For example, |
106 | when the code below is run (without the B<-w> flag), the second call |
107 | to C<doit> will trip a C<"Use of uninitialized value"> warning, whereas |
108 | the first will not. |
109 | |
110 | sub doit |
111 | { |
112 | my $b ; chop $b ; |
113 | } |
114 | |
115 | doit() ; |
116 | |
117 | { |
118 | local ($^W) = 1 ; |
119 | doit() |
120 | } |
121 | |
122 | This is a side-effect of C<$^W> being dynamically scoped. |
123 | |
124 | Lexical warnings get around these limitations by allowing finer control |
125 | over where warnings can or can't be tripped. |
126 | |
127 | =head2 Controlling Warnings from the Command Line |
128 | |
129 | There are three Command Line flags that can be used to control when |
130 | warnings are (or aren't) produced: |
131 | |
132 | =over 5 |
133 | |
134 | =item B<-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 | |
143 | If the B<-W> flag is used on the command line, it will enable all warnings |
144 | throughout the program regardless of whether warnings were disabled |
145 | locally using C<no warning> or C<$^W =0>. This includes all files that get |
146 | included via C<use>, C<require> or C<do>. |
147 | Think of it as the Perl equivalent of the "lint" command. |
148 | |
149 | =item B<-X> |
150 | |
151 | Does the exact opposite to the B<-W> flag, i.e. it disables all warnings. |
152 | |
153 | =back |
154 | |
155 | =head2 Backward Compatibility |
156 | |
157 | If you are used with working with a version of Perl prior to the |
158 | introduction of lexically scoped warnings, or have code that uses both |
159 | lexical warnings and C<$^W>, this section will describe how they interact. |
160 | |
161 | How Lexical Warnings interact with B<-w>/C<$^W>: |
162 | |
163 | =over 5 |
164 | |
165 | =item 1. |
166 | |
167 | If none of the three command line flags (B<-w>, B<-W> or B<-X>) that |
168 | control warnings is used and neither C<$^W> or lexical warnings are used, |
169 | then default warnings will be enabled and optional warnings disabled. |
170 | This means that legacy code that doesn't attempt to control the warnings |
171 | will work unchanged. |
172 | |
173 | =item 2. |
174 | |
175 | The B<-w> flag just sets the global C<$^W> variable as in 5.005 -- this |
176 | means that any legacy code that currently relies on manipulating C<$^W> |
177 | to control warning behavior will still work as is. |
178 | |
179 | =item 3. |
180 | |
181 | Apart from now being a boolean, the C<$^W> variable operates in exactly |
182 | the same horrible uncontrolled global way, except that it cannot |
183 | disable/enable default warnings. |
184 | |
185 | =item 4. |
186 | |
187 | If a piece of code is under the control of the lexical warning pragma, |
188 | both the C<$^W> variable and the B<-w> flag will be ignored for the |
189 | scope of the lexical warning. |
190 | |
191 | =item 5. |
192 | |
193 | The only way to override a lexical warnings setting is with the B<-W> |
194 | or B<-X> command line flags. |
195 | |
196 | =back |
197 | |
198 | The combined effect of 3 & 4 is that it will will allow code which uses |
199 | the lexical warning pragma to control the warning behavior of $^W-type |
200 | code (using a C<local $^W=0>) if it really wants to, but not vice-versa. |
201 | |
202 | =head1 EXPERIMENTAL FEATURES |
203 | |
204 | The features described in this section are experimental, and so subject |
205 | to change. |
206 | |
207 | =head2 Category Hierarchy |
208 | |
209 | A tentative hierarchy of "categories" have been defined to allow groups |
210 | of warnings to be enabled/disabled in isolation. The current |
211 | hierarchy is: |
212 | |
213 | all - +--- unsafe -------+--- taint |
214 | | | |
215 | | +--- substr |
216 | | | |
217 | | +--- signal |
218 | | | |
219 | | +--- closure |
220 | | | |
221 | | +--- untie |
222 | | | |
223 | | +--- utf8 |
224 | | |
225 | +--- io ---------+--- pipe |
226 | | | |
227 | | +--- unopened |
228 | | | |
229 | | +--- closed |
230 | | | |
231 | | +--- newline |
232 | | | |
233 | | +--- exec |
234 | | |
235 | +--- syntax ----+--- ambiguous |
236 | | | |
237 | | +--- semicolon |
238 | | | |
239 | | +--- precedence |
240 | | | |
241 | | +--- reserved |
242 | | | |
243 | | +--- octal |
244 | | | |
245 | | +--- parenthesis |
246 | | | |
247 | | +--- deprecated |
248 | | | |
249 | | +--- printf |
250 | | |
251 | +--- severe ----+--- inplace |
252 | | | |
253 | | +--- internal |
254 | | | |
255 | | +--- debugging |
256 | | |
257 | |--- uninitialized |
258 | | |
259 | +--- void |
260 | | |
261 | +--- recursion |
262 | | |
263 | +--- redefine |
264 | | |
265 | +--- numeric |
266 | | |
267 | +--- once |
268 | | |
269 | +--- misc |
270 | |
271 | |
272 | Just like the "strict" pragma any of these categories can be |
273 | combined |
274 | |
275 | use warning qw(void redefine) ; |
276 | no warning qw(io syntax untie) ; |
277 | |
278 | =head2 Fatal Warnings |
279 | |
280 | This feature is B<very> experimental. |
281 | |
282 | The presence of the word "FATAL" in the category list will escalate any |
283 | warnings from the category specified that are detected in the lexical |
284 | scope into fatal errors. In the code below, there are 3 places where |
285 | a deprecated warning will be detected, the middle one will produce a |
286 | fatal error. |
287 | |
288 | |
289 | use warning ; |
290 | |
291 | $a = 1 if $a EQ $b ; |
292 | |
293 | { |
294 | use warning qw(FATAL deprecated) ; |
295 | $a = 1 if $a EQ $b ; |
296 | } |
297 | |
298 | $a = 1 if $a EQ $b ; |
299 | |
300 | =head1 TODO |
301 | |
302 | The experimental features need bottomed out. |
303 | |
304 | perl5db.pl |
305 | The debugger saves and restores C<$^W> at runtime. I haven't checked |
306 | whether the debugger will still work with the lexical warnings |
307 | patch applied. |
308 | |
309 | diagnostics.pm |
310 | I *think* I've got diagnostics to work with the lexical warnings |
311 | patch, but there were design decisions made in diagnostics to work |
312 | around the limitations of C<$^W>. Now that those limitations are gone, |
313 | the module should be revisited. |
314 | |
315 | |
316 | =head1 SEE ALSO |
317 | |
318 | L<warning>. |
319 | |
320 | =head1 AUTHOR |
321 | |
322 | Paul Marquess |