Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

hashref value comparison

by geektron (Curate)
on Aug 17, 2007 at 19:22 UTC ( #633373=perlquestion: print w/ replies, xml ) Need Help??
geektron has asked for the wisdom of the Perl Monks concerning the following question:

I just got bit by a nasty bug and I'm trying to figure out how this error snuck through my checks. The top-level call:
my $respCodes = $processor->delayedCapture( CCTYPE => $row->{debitacct}, + ORIGID => $row->{auth_code}, CURRENCY_TYPE_ID => $row->{currency_type_id} ); croak "Failed authorization for TXID $row->{txid} " unless ( $respCodes->{SUCCESS} == 1 );
I'm performing an equality test, so I would think that if  $responseCode doesn't equal 1, this routine would  croak

But it gets slightly more complicated. The called routine ( processPayment() ) performs a similar hashref key comparison when building up its return value.

return { SUCCESS => $response->{RESULT} == 0, MESSAGE => $response->{RESPMSG}, AUTHCODE => $response->{AUTHCODE}, PNREF => $response->{PNREF}, CC_TYPE => $params{CCTYPE}, TOTAL_PAYMENT => $params{AMOUNT}, CHECK_DETAILS => $checkInfo, };
If $response is still a scalar (meaning that nothing happened to it after declaring it in the subroutine), shouldn't the value of $response->{SUCCESS} be  undef (due to autovivification) rather than having  $response->{SUCCESS} == 0 evaluate to true?

I see where the caller ( the first calls listed in this entry ) would make the mistake with the hashkey comparison since the error was introduced in  $processor->delayedCapture() . But how can  $foo->{bar} == 0 evaluate to true?

I don't know if my solution is the best one, but I've added a  defined check in the creation of the return value of  delayedCapture() :

return { SUCCESS => ( defined $response->{RESULT} && $response->{RE +SULT} == 0 ), ....

Comment on hashref value comparison
Select or Download Code
Re: hashref value comparison
by kyle (Abbot) on Aug 17, 2007 at 19:29 UTC

    When undef is treated as a number, it's equal to zero. When it's treated as a string, it's equal to ''.

    $ perl -le 'print "true" if undef == 0;' true $ perl -le 'print "true" if undef eq "";' true

    Checking to make sure the value is defined before comparing to zero is the right way to go.

      Thanks.

      I don't know why I thought  undef acted more like a NULL value ...

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://633373]
Approved by kyle
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (10)
As of 2015-07-03 11:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (51 votes), past polls