Re: OOP style question: Checking a value

My answer: "6. None of the above".

As Tanktalus already explained, it feels strange to check for the response code AFTER you have called a method on an object.

In my book of programming with objects I always like the object on which a method is called to directly return some meaningful code to the caller.

It is up to the caller to either call the object in a void context (essentially throwing the return value away) or saving the return value and acting upon it later.

If you need more than a simple "true" or "false" value returned, why not go all the way and have your objects return full blown response-objects? You could make this response object stringify to one of your constants or call other methods on it (logging, stack-traces; full exception handling; ... etc).

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Comment on Re: OOP style question: Checking a value

Replies are listed 'Best First'.
Re^2: OOP style question: Checking a value by spq (Friar) on Aug 29, 2006 at 21:42 UTC
Because many, if not most, of the methods already return something useful. And as I said in an earlier response, I need to have some of these codes (yes there are more than just true/false) available for a certain specific subset of methods, and so started reusing them for other purposes, since they made sense for some other things, including where a failure state could have different causes that I may want to handle differently. Sure there are other ways of doing it, and suggestions are welcome. But even if I ceased reusing these codes there are still a small subset of methods that would required some variation of the style question originally posed.	[reply]

Replies are listed 'Best First'.

Re^2: OOP style question: Checking a value
by spq (Friar) on Aug 29, 2006 at 21:42 UTC

Because many, if not most, of the methods already return something useful. And as I said in an earlier response, I need to have some of these codes (yes there are more than just true/false) available for a certain specific subset of methods, and so started reusing them for other purposes, since they made sense for some other things, including where a failure state could have different causes that I may want to handle differently. Sure there are other ways of doing it, and suggestions are welcome.

But even if I ceased reusing these codes there are still a small subset of methods that would required some variation of the style question originally posed.

[reply]