[sf-perl] Related to Perl Best Practices / a Perl::Critic Rule
Paul.Makepeace at realprogrammers.com
Thu Feb 25 22:03:56 PST 2010
On Fri, Feb 26, 2010 at 02:48, Quinn Weaver <quinn at fairpath.com> wrote:
> Damian thinks you should always check return values of builtins (or throw
> exceptions—the theory is that halting is safer than continuing in case
> things go pear-shaped).
There is definitely some mileage to checking print & close(!) when
doing IPC. That stuff can really be a PITA to debug. Knowing your
close failed, i.e. exactly where can really save a lot of time.
On the whole though it definitely strikes me as counter-pragmatic...
(or yet another reason to have native exceptions in a language ;))
> I tend to use autodie; for this kind of thing. I also tend to have a
> top-level eval that catches any otherwise uncaught exception and bails
> appropriately (if I'm not already working in a framework that does that for
> Quinn Weaver Consulting, LLC
> Full-stack web design and development
> On Feb 25, 2010, at 7:34 AM, Brian Friday <brian.friday at gmail.com> wrote:
>> There is one specific Perl::Critic rule that confounds me and I am
>> wondering if anyone can shed any light into the why of it.
>> You have a Perl program with:
>> print "Something\n";
>> Run it through Perl::Critic and you get the following error:
>> Return value of flagged function ignored - print at line 27, column 1.
>> See pages 208,278 of PBP. (Severity: 1)
>> Change the line to:
>> print "Something\n" or croak "blah\n";
>> Perl::Critic no longer has any issues with the code, life continues on.
>> If the print had a $var call in it, this croak does not stop you from
>> printing on uninitialized values. I have been mulling it over but for print
>> itself I have not been able to find a definitive "this is a good idea
>> because...." .
>> I treat the PBP and Perl::Critic as a guide to good Perl coding behavior
>> and not a book of rules. That said I like to understand a rule before I
>> throw it out. This rule just happens to be one I come back to because no
>> answer I have come up with pushes me over the use it side or lose it side of
>> the fence.
>> - Brian
>> SanFrancisco-pm mailing list
>> SanFrancisco-pm at pm.org
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
More information about the SanFrancisco-pm