Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
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 imbibing at the Monastery: (4)
As of 2014-07-26 08:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (175 votes), past polls