X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=pod%2Fperllexwarn.pod;h=0052d33ff2bc44e2d25461e6eef4cf8f9fb3347e;hb=1e6da01743571311bdbed539271d576c28f4c2ec;hp=af1a910334d5395f29fc43eff18db053e99e51a7;hpb=c47ff5f1a1ef5d0daccf1724400a446cd8e93573;p=p5sagit%2Fp5-mst-13.2.git diff --git a/pod/perllexwarn.pod b/pod/perllexwarn.pod index af1a910..0052d33 100644 --- a/pod/perllexwarn.pod +++ b/pod/perllexwarn.pod @@ -9,7 +9,7 @@ flag B<-w> and the equivalent Perl variable, C<$^W>. The pragma works just like the existing "strict" pragma. This means that the scope of the warning pragma is limited to the -enclosing block. It also means that that the pragma setting will not +enclosing block. It also means that the pragma setting will not leak across files (via C, C or C). This allows authors to independently define the degree of warning checks that will be applied to their module. @@ -195,7 +195,7 @@ or B<-X> command line flags. =back -The combined effect of 3 & 4 is that it will will allow code which uses +The combined effect of 3 & 4 is that it will allow code which uses the C pragma to control the warning behavior of $^W-type code (using a C) if it really wants to, but not vice-versa. @@ -339,20 +339,49 @@ fatal error. =head2 Reporting Warnings from a Module -The C pragma provides two functions, namely C -and C, that are useful for module authors. They are -used when you want to report a module-specific warning, but only when -the calling module has enabled warnings via the C pragma. +The C pragma provides a number of functions that are useful for +module authors. These are used when you want to report a module-specific +warning when the calling module has enabled warnings via the C +pragma. -Consider the module C below. +Consider the module C below. - package abc; + package MyMod::Abc; - sub open - { + use warnings::register; + + sub open { + my $path = shift ; + if (warnings::enabled() && $path !~ m#^/#) { + warnings::warn("changing relative path to /tmp/"); + $path = "/tmp/$path" ; + } + } + + 1 ; + +The call to C will create a new warnings category +called "MyMod::abc", i.e. the new category name matches the module +name. The C function in the module will display a warning message +if it gets given a relative path as a parameter. This warnings will only +be displayed if the code that uses C has actually enabled +them with the C pragma like below. + + use MyMod::Abc; + use warnings 'MyMod::Abc'; + ... + abc::open("../fred.txt"); + +It is also possible to test whether the pre-defined warnings categories are +set in the calling module with the C function. Consider +this snippet of code: + + package MyMod::Abc; + + sub open { if (warnings::enabled("deprecated")) { warnings::warn("deprecated", - "abc::open is deprecated. Use abc:new") ; + "open is deprecated, use new instead") ; } new(@_) ; } @@ -366,21 +395,21 @@ display a warning message whenever the calling module has (at least) the "deprecated" warnings category enabled. Something like this, say. use warnings 'deprecated'; - use abc; + use MyMod::Abc; ... - abc::open($filename) ; - + MyMod::Abc::open($filename) ; -If the calling module has escalated the "deprecated" warnings category -into a fatal error like this: +The C function should be used to actually display the +warnings message. This is because they can make use of the feature that +allows warnings to be escalated into fatal errors. So in this case - use warnings 'FATAL deprecated'; - use abc; + use MyMod::Abc; + use warnings FATAL => 'MyMod::Abc'; ... - abc::open($filename) ; + MyMod::Abc::open('../fred.txt'); -then C will detect this and die after displaying the -warning message. +the C function will detect this and die after +displaying the warning message. =head1 TODO