In perl.git, the branch blead has been updated <http://perl5.git.perl.org/perl.git/commitdiff/2e4abf26cb063448238056754343185a65d15b21?hp=abec5bedacd77b2152e61ec3216ab47bd7272fc9>
- Log ----------------------------------------------------------------- commit 2e4abf26cb063448238056754343185a65d15b21 Author: David Golden <[email protected]> Date: Mon Mar 23 11:51:09 2015 -0400 discourage use warnings FATAL => 'all' After additional discussions on perl5-porters and #p5p, no one seems to be violently objecting to the idea that FATAL warnings need a much stronger warning about risks and that FATAL => 'all' should actually be 'discouraged' in the official, perlpolicy sense. The text of this commit has been posted to perl5-porters for discussion and approved by those who objected to earlier language. I dare not call it "consensus" for fear of the consequences, but no one has raised further obstacles to making this change. ----------------------------------------------------------------------- Summary of changes: lib/warnings.pm | 72 +++++++++++++++++++++++++++++------------- pod/perldelta.pod | 11 +++++++ regen/warnings.pl | 72 +++++++++++++++++++++++++++++------------- t/porting/known_pod_issues.dat | 1 + 4 files changed, 112 insertions(+), 44 deletions(-) diff --git a/lib/warnings.pm b/lib/warnings.pm index cad00ea..e47ced4 100644 --- a/lib/warnings.pm +++ b/lib/warnings.pm @@ -5,7 +5,7 @@ package warnings; -our $VERSION = '1.31'; +our $VERSION = '1.32'; # Verify that we're called correctly so that warnings will work. # see also strict.pm. @@ -880,9 +880,55 @@ is now a top-level category in its own right. =head2 Fatal Warnings X<warning, fatal> -The presence of the word "FATAL" in the category list will escalate any -warnings detected from the categories specified in the lexical scope -into fatal errors. In the code below, the use of C<time>, C<length> +The presence of the word "FATAL" in the category list will escalate +warnings in those categories into fatal errors in that lexical scope. + +B<NOTE:> FATAL warnings should be used with care, particularly +C<< FATAL => 'all' >>. + +Libraries using L<warnings::warn|/FUNCTIONS> for custom warning categories +generally don't expect L<warnings::warn|/FUNCTIONS> to be fatal and can wind up +in an unexpected state as a result. For XS modules issuing categorized +warnings, such unanticipated exceptions could also expose memory leak bugs. + +Moreover, the Perl interpreter itself has had serious bugs involving +fatalized warnings. For a summary of resolved and unresolved problems as +of January 2015, please see +L<this perl5-porters post|http://www.nntp.perl.org/group/perl.perl5.porters/2015/01/msg225235.html>. + +While some developers find fatalizing some warnings to be a useful +defensive programming technique, using C<< FATAL => 'all' >> to fatalize +all possible warning categories -- including custom ones -- is particularly +risky. Therefore, the use of C<< FATAL => 'all' >> is +L<discouraged|perlpolicy/discouraged>. + +The L<strictures|strictures/VERSION-2> module on CPAN offers one example of +a warnings subset that the module's authors believe is relatively safe to +fatalize. + +B<NOTE:> users of FATAL warnings, especially those using +C<< FATAL => 'all' >>, should be fully aware that they are risking future +portability of their programs by doing so. Perl makes absolutely no +commitments to not introduce new warnings or warnings categories in the +future; indeed, we explicitly reserve the right to do so. Code that may +not warn now may warn in a future release of Perl if the Perl5 development +team deems it in the best interests of the community to do so. Should code +using FATAL warnings break due to the introduction of a new warning we will +NOT consider it an incompatible change. Users of FATAL warnings should +take special caution during upgrades to check to see if their code triggers +any new warnings and should pay particular attention to the fine print of +the documentation of the features they use to ensure they do not exploit +features that are documented as risky, deprecated, or unspecified, or where +the documentation says "so don't do that", or anything with the same sense +and spirit. Use of such features in combination with FATAL warnings is +ENTIRELY AT THE USER'S RISK. + +The following documentation describes how to use FATAL warnings but the +perl5 porters strongly recommend that you understand the risks before doing +so, especially for library code intended for use by others, as there is no +way for downstream users to change the choice of fatal categories. + +In the code below, the use of C<time>, C<length> and C<join> can all produce a C<"Useless use of xxx in void context"> warning. @@ -935,24 +981,6 @@ C<< use warnings 'FATAL'; >>, C<< use warnings 'NONFATAL'; >> and C<< no warnings 'FATAL'; >> was unspecified; they did not behave as if they included the C<< => 'all' >> portion. As of 5.20, they do.) -B<NOTE:> Users of FATAL warnings, especially -those using C<< FATAL => 'all' >> -should be fully aware that they are risking future portability of their -programs by doing so. Perl makes absolutely no commitments to not -introduce new warnings, or warnings categories in the future, and indeed -we explicitly reserve the right to do so. Code that may not warn now may -warn in a future release of Perl if the Perl5 development team deems it -in the best interests of the community to do so. Should code using FATAL -warnings break due to the introduction of a new warning we will NOT -consider it an incompatible change. Users of FATAL warnings should take -special caution during upgrades to check to see if their code triggers -any new warnings and should pay particular attention to the fine print of -the documentation of the features they use to ensure they do not exploit -features that are documented as risky, deprecated, or unspecified, or where -the documentation says "so don't do that", or anything with the same sense -and spirit. Use of such features in combination with FATAL warnings is -ENTIRELY AT THE USER'S RISK. - =head2 Reporting Warnings from a Module X<warning, reporting> X<warning, registering> diff --git a/pod/perldelta.pod b/pod/perldelta.pod index 30960e6..afe91aa 100644 --- a/pod/perldelta.pod +++ b/pod/perldelta.pod @@ -49,6 +49,13 @@ XXX For a release on a stable branch, this section aspires to be: XXX Any deprecated features, syntax, modules etc. should be listed here. +=head2 Making all warnings fatal is discouraged + +The documentation for L<fatal warnings|warnings/Fatal Warnings> notes +that C<< use warnings FATAL => 'all' >> is discouraged +and provides stronger language about the risks of fatal warnings +in general. + =head2 Module removals XXX Remove this section if inapplicable. @@ -143,6 +150,10 @@ L<PerlIO::mmap> has been upgraded from version 0.013 to 0.014. L<attributes> has been upgraded from version 0.26 to 0.27. +=item * + +L<warnings> has been upgraded from version 1.31 to 1.32. + =back =head2 Removed Modules and Pragmata diff --git a/regen/warnings.pl b/regen/warnings.pl index be6466a..be33087 100644 --- a/regen/warnings.pl +++ b/regen/warnings.pl @@ -483,7 +483,7 @@ read_only_bottom_close_and_rename($pm); __END__ package warnings; -our $VERSION = '1.31'; +our $VERSION = '1.32'; # Verify that we're called correctly so that warnings will work. # see also strict.pm. @@ -996,9 +996,55 @@ is now a top-level category in its own right. =head2 Fatal Warnings X<warning, fatal> -The presence of the word "FATAL" in the category list will escalate any -warnings detected from the categories specified in the lexical scope -into fatal errors. In the code below, the use of C<time>, C<length> +The presence of the word "FATAL" in the category list will escalate +warnings in those categories into fatal errors in that lexical scope. + +B<NOTE:> FATAL warnings should be used with care, particularly +C<< FATAL => 'all' >>. + +Libraries using L<warnings::warn|/FUNCTIONS> for custom warning categories +generally don't expect L<warnings::warn|/FUNCTIONS> to be fatal and can wind up +in an unexpected state as a result. For XS modules issuing categorized +warnings, such unanticipated exceptions could also expose memory leak bugs. + +Moreover, the Perl interpreter itself has had serious bugs involving +fatalized warnings. For a summary of resolved and unresolved problems as +of January 2015, please see +L<this perl5-porters post|http://www.nntp.perl.org/group/perl.perl5.porters/2015/01/msg225235.html>. + +While some developers find fatalizing some warnings to be a useful +defensive programming technique, using C<< FATAL => 'all' >> to fatalize +all possible warning categories -- including custom ones -- is particularly +risky. Therefore, the use of C<< FATAL => 'all' >> is +L<discouraged|perlpolicy/discouraged>. + +The L<strictures|strictures/VERSION-2> module on CPAN offers one example of +a warnings subset that the module's authors believe is relatively safe to +fatalize. + +B<NOTE:> users of FATAL warnings, especially those using +C<< FATAL => 'all' >>, should be fully aware that they are risking future +portability of their programs by doing so. Perl makes absolutely no +commitments to not introduce new warnings or warnings categories in the +future; indeed, we explicitly reserve the right to do so. Code that may +not warn now may warn in a future release of Perl if the Perl5 development +team deems it in the best interests of the community to do so. Should code +using FATAL warnings break due to the introduction of a new warning we will +NOT consider it an incompatible change. Users of FATAL warnings should +take special caution during upgrades to check to see if their code triggers +any new warnings and should pay particular attention to the fine print of +the documentation of the features they use to ensure they do not exploit +features that are documented as risky, deprecated, or unspecified, or where +the documentation says "so don't do that", or anything with the same sense +and spirit. Use of such features in combination with FATAL warnings is +ENTIRELY AT THE USER'S RISK. + +The following documentation describes how to use FATAL warnings but the +perl5 porters strongly recommend that you understand the risks before doing +so, especially for library code intended for use by others, as there is no +way for downstream users to change the choice of fatal categories. + +In the code below, the use of C<time>, C<length> and C<join> can all produce a C<"Useless use of xxx in void context"> warning. @@ -1051,24 +1097,6 @@ C<< use warnings 'FATAL'; >>, C<< use warnings 'NONFATAL'; >> and C<< no warnings 'FATAL'; >> was unspecified; they did not behave as if they included the C<< => 'all' >> portion. As of 5.20, they do.) -B<NOTE:> Users of FATAL warnings, especially -those using C<< FATAL => 'all' >> -should be fully aware that they are risking future portability of their -programs by doing so. Perl makes absolutely no commitments to not -introduce new warnings, or warnings categories in the future, and indeed -we explicitly reserve the right to do so. Code that may not warn now may -warn in a future release of Perl if the Perl5 development team deems it -in the best interests of the community to do so. Should code using FATAL -warnings break due to the introduction of a new warning we will NOT -consider it an incompatible change. Users of FATAL warnings should take -special caution during upgrades to check to see if their code triggers -any new warnings and should pay particular attention to the fine print of -the documentation of the features they use to ensure they do not exploit -features that are documented as risky, deprecated, or unspecified, or where -the documentation says "so don't do that", or anything with the same sense -and spirit. Use of such features in combination with FATAL warnings is -ENTIRELY AT THE USER'S RISK. - =head2 Reporting Warnings from a Module X<warning, reporting> X<warning, registering> diff --git a/t/porting/known_pod_issues.dat b/t/porting/known_pod_issues.dat index 3e2893a..7d53853 100644 --- a/t/porting/known_pod_issues.dat +++ b/t/porting/known_pod_issues.dat @@ -193,6 +193,7 @@ SOM splain sprintf(3) stat(2) +strictures String::Base String::Scanf Switch -- Perl5 Master Repository
