in reply to OOP style question: Checking a value

spg

If anything, no 5. 1 & 2 make the OK look far too much like a bareword which is uncomfortable when using strictures. 3 & 4 needlessly repeat the object name, so 5 is the most compact. But why not test for truth and only look at the response when the return value fails?

if ( $client->response ) { #then do whatever } else { #probe for the bad news here }
Or as you suggest, you could use an eval, but why?

jdtoronto

Replies are listed 'Best First'.
Re^2: OOP style question: Checking a value
by spq (Friar) on Aug 29, 2006 at 21:04 UTC

    Sure. But a response code is always set, so in you example above you would be checking $client->foo's result in the if (){}. Otherwise though, I leave how to structure the code checking foo's result and looking at the response code to the users preferences. ;) And I still need to define how they probe for the bad news. ... Oh, perhaps I wasn't clear. There are far more than just pass/fail (OK/ERROR) as possible response codes.

    The primary target for the code in this project is a related mod_perl project. While I've reused the same massaging and response codes for my own error checking and testing (and far more code uses them for those purposes), the response code values are actually the same as used by Apache, and as such can be meaningfully returned to a client (browser) with the correct meaning in the appropriate circumstances.

    So that's one vote for #5. Thanks!