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

[Paul Makepeace]

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
> 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
>