Which safety net do you use in Perl? - perl

Question

Which safety net do you use?
use warnings;
or
use strict;
I know that
A potential problem caught by use
strict; will cause your code to stop
immediately when it is encountered,
while use warnings; will merely give a
warning (like the command-line switch
-w) and let your code run.
Still I want to know that which one is mostly used by the Perl-programmers. Which one they have seen being used the most?

Answer 1

Both, of course. If perl were designed today, use strict and use warnings would be the default behavior. It's just like having warnings turned on in a compiler - why would you not do that by default?

Answer 2

What you have doesn’t even start to be enough.
I use code approximating this as a starting point. It works well in my environment, although as always your mileage may vary.
#!/usr/bin/env perl
use v5.12;
use utf8;
use strict;
use autodie;
use warnings;
use warnings qw< FATAL utf8 >;
use feature qw< unicode_strings >;
use open qw< :std :utf8 >;
use charnames qw< :full >;
# These are core modules:
use Carp qw< carp croak confess cluck >;
use File::Basename qw< basename dirname >;
use Unicode::Normalize qw< NFD NFKD NFC NFKC >;
use Getopt::Long qw< GetOptions >;
use Pod::Usage qw< pod2usage >;
our $VERSION = v0.0.1;
$0 = basename($0); # shorter messages
## $| = 1;
$SIG{__DIE__} = sub {
confess "Uncaught exception: #_" unless $^S;
};
$SIG{__WARN__} = sub {
if ($^S) { cluck "Trapped warning: #_" }
else { confess "Deadly warning: #_" }
};
END {
local $SIG{PIPE} = sub { exit };
close STDOUT;
}
if (grep /\P{ASCII}/ => #ARGV) {
#ARGV = map { decode("UTF-8", $_) } #ARGV;
}
binmode(DATA, ":utf8");
## Getopt::Long::Configure qw[ bundling auto_version ];
if (!#ARGV && -t STDIN) {
print STDERR "$0: reading from stdin: type ^D to end, ^C to kill...\n";
}
while (<>) {
$_ = NFD($_);
# ...
print NFC($_);
}
exit;
=pod
=encoding utf8
=head1 NAME
=head1 SYNOPSIS
=head1 DESCRIPTION
=head1 OPTIONS
=head1 EXAMPLES
=head1 ERRORS
=head1 FILES
=head1 ENVIRONMENT
=head1 PROGRAMS
=head1 AUTHOR
=head1 COPYRIGHT AND LICENCE
=head1 REVISION HISTORY
=head1 BUGS
=head1 TODO
=head1 SEE ALSO
=cut
__END__
Your UTF-8 data goes here.
You can find more examples of this sort of thing in action in the Perl Unicode Tool Chest, currently up to around 50 files ranging from the simple to the sublime.

Answer 3

use strict generates an error if you use symbolic references (ie, strings to represent names of symbols). It generates an error if you use a variable without declaring it (this encourages the use of lexical 'my' variables, but is also satisfied if you properly declare package globals). It also generates an error if you leave barewords hanging around in the script (unquoted strings, essentially, by Perl's definition of quotes). With 'strict', you may enable or disable any of three categories of strictures, and my do so within scoped blocks. It is a best practice to enable strictures, though on occasion legitimate code requires that some of its features be locally disabled. However, one should think long and hard about whether this is really necessary, and whether their solution is ideal. You can read about strictures in Perl's POD entitled 'strict'.
use warnings generates a warning message based on many criteria, which are described in the POD 'perllexwarn'. These warnings have nothing to do with strictures, but rather, watch for the most common "gotchas" one is likely to encounter in their programming. It is a best practice to use warnings while writing scripts too. In some cases where the message might be undesirable a certain warning category may be locally disabled within a scope. Additional info is described in 'warnings'.
use diagnostics makes the warnings more verbose, and in a development or learning environment, particularly among newcomers, that's highly desirable. Diagnostics would probably be left out of a 'final product', but while in development they can be a really nice addition to the terse messages normally generated. You can read about diagnostics in the Perl POD "diagnostics."
There is no reason to force oneself to use only one of the above options or another. In particular, use warnings and use strict should generally both be used in modern Perl programs.
In all cases (except diagnostics, which you're only using for development anyway), individual strictures or warnings may be lexically disabled. Furthermore, their errors may be trapped with eval{ .... }, with Try::Tiny's try/catch blocks, and a few other ways. If there's a concern about a message giving a potential attacker more information about a script, the messages could be routed to a logfile. If there's a risk of said logfile consuming lots of space, there's a bigger issue at hand, and the source of the issue should either be resolved or in some rare cases simply have the message disabled.
Perl programs nowadays should be highly strict/warnings compliant as a best practice.

Answer 4

Use both, as the linked page says.
The documentation is perhaps a bit unclear. use strict and use warnings catch different problems; use strict will not cause your program to immediately exit when mere warnings are encountered, only when you violate the strict syntax requirements. You will still get only warnings printed when your code does things that are less seriously bad.

Answer 5

use strict;
#use warnings;
use diagnostics; # "This module extends the terse diagnostics..." by http://perldoc.perl.org/diagnostics.html
Both! But I prefer diagnostics, instead of warnings, which give you some more information.