Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

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 ), ....

Replies are listed 'Best First'.
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.


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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://633373]
Approved by kyle
beech *me* ... test
[beech]: ...
beech me *me* ... test me *me* test
[beech]: me
[beech]: ... test

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (3)
As of 2017-03-28 23:46 GMT
Find Nodes?
    Voting Booth?
    Should Pluto Get Its Planethood Back?

    Results (343 votes). Check out past polls.