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:
I'm performing an equality test, so I would think that if $responseCode doesn't equal 1, this routine would croakmy $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 );
But it gets slightly more complicated. The called routine ( processPayment() ) performs a similar hashref key comparison when building up its return value.
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?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, };
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 | |
by geektron (Curate) on Aug 17, 2007 at 20:17 UTC |
Back to
Seekers of Perl Wisdom