[sf-perl] Related to Perl Best Practices / a Perl::Critic Rule

[Jonathan Swartz]

Ok - but seriously -

    print "Something\n";

???

Seems like there ought to be an exception to the rule for that.

I've never noticed critic complaining about this, but I run at level 3.

On Feb 25, 2010, at 10:48 AM, Quinn Weaver 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).
>
> 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 me).
>
> --
> Quinn Weaver Consulting, LLC
> Full-stack web design and development
> http://quinnweaver.com/
> 510-520-5217
>
>
> 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...." .
>>
>> Thoughts?
>>
>> 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
>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm