Hack #83. Write Your Own Warnings
Improve static code checking.
You have strict under
control. You know why you use warnings. Maybe you even use B::Lint to find problems. Are they truly enough for you? If you've ever wished that you could make strict stricter or make warnings preachier, you're in luck.
Tip
Perl::Critic is a similarly
excellent tool that audits your code based on Damian Conway's Perl Best Practices (O'Reilly).
The Hack
It's impossible to override some built-in functions[19]
[Hack #91] like print( ) and printf( ). Usually print( ) succeeds because it writes to an internal buffer—but occasionally Perl has to flush the buffer. print( ) might fail if you write to a file on a full file system, to a closed handle, or for any of several other reasons. If you don't check print( ) and close( ) for success, you might lose data without knowing about it.
The best you can do for unoverridable functions is to create new warnings for unsafe code.
Here's bad_style.pl, a short program that opens a file and writes something to it. It has three misfeatures: ignoring the results of print( ) and close( ) and a terribly non-descriptive variable name:
open my $fh, '>>', 'bad_style.txt'
or die "Can't open bad_style.txt for appending: $!\\n";
print {$fh} 'Hello!';
close $fh;You could review every line of code in your
system to find these errors. Better yet, teach B::Lint how to find them for you:
package B::Lint::VoidSyscalls; use strict; use warnings; use B 'OPf_WANT_VOID'; use B::Lint; ...