When Perl 5.6.0 introduced lexical warnings, it gave programmers finer control over what parts of their program would produce warnings and how to handle those warnings. The most important feature is that the warnings pragma has a lexical effect. In other words, rather than enabling warnings for the entire program unilaterally, some files and blocks can request stricter or looser warning categories than others.
Whole-Program Robustness is Not a Library Concern
This is especially important for Perl applications which are often a combination of custom code and CPAN modules. Even though the CPAN is free and open source software and even though many of the newer CPAN distributions have public source control repositories to which you can submit patches and feature requests, there's often a thick line between "code we maintain for this project" and "code someone else maintains". Lexical warnings mean that the maintainers of CPAN distributions can choose their own warning strategies and your team can choose your own warning strategy and those strategies don't have to be the same.
Keep that separation of concerns in mind for a moment.
Blurring the Lines Between Warnings and Exceptions
The warnings pragma also included a feature which can promote any warnings caused in a lexical scope into exceptions. If, for the purpose of security or clarity or maintainability or coding standards, your team decides that uninitialized value warnings are so severe that they should be exceptional conditions, you can ask the warnings pragma to promote that warning to an exception within a lexical scope. This is a powerful feature that you should use with caution; unless you're prepared to catch those exceptions and deal with them (or not catch them and deal with the consequences), those exceptions will cause your program to terminate. That may be what you want, but if you've asked for it explicitly, Perl believes you know what you're doing.
Perl also gives you the option to promote all warnings in
every warning category to an exception with use warnings FATAL
=> 'all';. If enabling fatal warnings for one warning category is
serious, promoting all warnings to exceptions is grave.
Promoting Library Warnings to Exceptions
The warnings pragma also added an interesting feature by which
modules can register their own categories of warnings. Perl will treat them as
lexical warnings just as if they were core warnings. In other words, a module
which chooses to register its own warning category will be able to emit
warnings which respect a use warnings; or no
warnings; in caller scopes.
This is a wonderful feature because it respects the separation of concerns. It's not up to a library to dictate what the users of that library consider warnable conditions. The users of that library can elect to accept warnings or disable them as they see fit.
Warnings registered with warnings also fall under the purview of the fatal warnings promotion code. If you've enabled fatal warnings and if any of the modules you use within that lexical scope emit a warning, that module's warning will become an exception.
Fatal Warnings are Not Future Proof
If you have the mindset for reading awkward bug reports, Perl RT #121085 demonstrates one serious danger of unilateral fatal warnings. Because you've asked Perl to treat all warnings as fatal, any warning you get will be fatal.
Because Perl, by default, does not treat warnings as fatal (because Perl uses the word "exception" to mean "exception" and "warning" to mean "warning", thus distinguishing between the two as a matter of syntax and semantics), it's possible that a newer major release of Perl may emit more warnings than a older major release of Perl. In fact, that happens. As Perl evolves and improves and Perl users discover more interesting and useful interactions with the language and as bugs get fixed, certain conditions lend themselves to error messages.
If you've written use warnings FATAL => 'all';, you've
accepted the responsibility for checking to see if a newer release of Perl
emits newer warnings. Even if you didn't know you had that responsibility, you
should have known. That's what you asked for. Your program threw an exception
and you didn't catch it. That's your responsibility.
Many people know that. That fact is rarely controversial. If you read the RT #121085 bug report, you'll see the argument that p5p should be extra careful adding new warnings because some people choose to treat them as exceptions, and so they're effectively exceptions, and p5p is causing previously valid programs to break—but that's a silly argument.
Perl developers brag rightly about Perl's commitment to backwards compatibility, but an understated corollary to backwards compatibility is forwards compatibility. It's your responsibility as a developer to write code that's compatible with future releases of Perl (within reason) or to face the consequences. If you write code that is likely to break when upgrading to a new version of Perl, that's your fault. p5p will do its best to ease the transition (that's why deprecations are multi-year processes which begin with warnings and eventually become exceptions), but you have a responsibility too.
That fact is a little bit more controversial, but it's pretty well established on p5p. It's not at all well established on the CPAN, which is where the problem gets a lot more serious and subtle.
Remember how modules can register their own lexical warnings? Just as Perl may add new warnings in major releases, modules can add new warnings—except that CPAN modules can add new warnings whenever they see fit, because there are no normative community standards about when it's acceptable to add new warnings, how often releases will happen, how long the support period for releases is, and any commitment to backwards compatibility or deprecation.
If you've enabled fatal warnings, you've asked for any warnings in any CPAN module that you didn't write and you don't maintain to become exceptions which may terminate your program. The risk isn't "We upgrade our core Perl once a year and read the list of changes then run our entire test suite and only then deploy a new version". The risk is "We've updated CPAN modules and now have to audit all of them for new warnings."
That's a bigger risk—but it gets worse.
Fatal Warnings Do Not Belong in Module Code
What if a CPAN module you use but do not maintain uses fatal warnings? Any change to its dependencies which throws a warning the module did not account for may now throw an exception. Because it's in code you do not maintain, it's time to break out the debugger to figure out what went wrong, then fire off a patch and hope the maintainer releases a new version. In the meantime, your code is broken because a CPAN maintainer did not think about the risk of promoting warnings to exceptions for circumstances which are outside of his or her control.
Such a CPAN module is, by default, vulnerable to a change in any of its dependencies which may legitimately produce new warnings. By "vulnerable" I mean "your program may start crashing in library code you didn't write and do not maintain and, by the way, may be in a dependency several levels deep that you didn't even know enabled fatal warnings".
You can make the argument that—in limited, well-controlled, and lexical circumstances—it's possible to write robust code which promotes specific warnings to exceptions. This can make code safer and stronger, if it's tested well and if the extent of that promotion is understood very well. Traditionally, that hasn't happened; it's been all or nothing.
The choice to treat all warnings as fatal (especially knowing that "all" can change between versions of Perl) should be left to the user of code. You know your environment. You know your ability to check logs and errors and update code after hours and on the weekends. You know what kind of user input you get.
You know the cost of a program exiting due to an unforeseen error and whether that error represents a real risk to your business purposes or something that someone could safely clear up on Monday morning after sufficient caffeination.
The real problem is that use warnings FATAL =>
'all'; does not belong in library code that you're handing
other people to use. It's just too risky.
