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

[Quinn Weaver]

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