Your skill will accomplish what the force of many cannot |
|
PerlMonks |
hashref value comparisonby geektron (Curate) |
on Aug 17, 2007 at 19:22 UTC ( [id://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:
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. 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():
Back to
Seekers of Perl Wisdom
|
|