Writing setter methods - return void or boolean

techguy

Hi,

Just a quick question. I'm doing a lot of practice on OOP at the moment, writing get and set methods etc..

So far for the set methods we (class) have been just returning void (nothing).. I'm just wondering would it be better if I was to return a boolean so we could use that in the main program e.g if(set) or if(!set)

Does this make any odds? I'm just wondering?

Thanks..

seamus

Depends on the language really. In Java for example, afaik the "correct" way to do it is to set the variable or throw an exception if it cannot be set (connection failure, invalid value, etc). In other languages where exception handling isn't quite so robust, a boolean return value may be more appropriate.

techguy

seamus wrote: »

Depends on the language really. In Java for example, afaik the "correct" way to do it is to set the variable or throw an exception if it cannot be set (connection failure, invalid value, etc). In other languages where exception handling isn't quite so robust, a boolean return value may be more appropriate.

Ahh, I see.. Thats does sound like a better way of doing it, I am familiar with exceptions so I will use that method on any proper programs I am making.

My question came from PHP where they use a boolean..

Solved!

Thanks..

seamus

techguy wrote: »

My question came from PHP where they use a boolean..

My current speciality is PHP, so I was about to give your proposal the thumbs up, but then I remembered the Java model I learned in college.

techguy

Cool, I hope to have PHP, Java and C# as my main languages!

Civilian_Target

general rule in Java: void for set, boolean for add or addAll (eg. add X to a collection)
If in doubt, look at the API doc

Giblet

Set methods should be as simple as possible, setting the variable. You shouldn't be using set's to do anything too complicated as the implementation might be hidden and the user might not know about the complexity behind setName or something. You'd be better off using a more descriptive name.

You'll see this when it comes to C# and auto implemented properties, very handy for quickly building simple apps as well.

fasty

As has been suggested, throw exceptions if the language supports it, otherwise return void if it's something simple, why would something not get set in a strongly typed language? No need to pepper your code with

if(set(somevalue)) DoSomethingElse();

I guess for PHP it makes sense to return a boolean or something...

Malached

Gaaaaaaarrggh ...... True OOP .... Identity, State, Behaviour. Should be no setter/getters. However, in the real world, return what is appropriate. If you depend on a list of ****, return list[****] or empty list. If you return on something vital, throw exception or equivalent ...... etc. etc.