Home/ Questions/Q 832749
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T04:24:37+00:00

Possible Duplicate: Convention question: When do you use a Getter/Setter function rather than using

  • 0

Possible Duplicate:
Convention question: When do you use a Getter/Setter function rather than using a Property

I’ve run into a lot of differing opinions on Getters and Setters lately, so I figured I should make it into it’s own question.

A previous question of mine received an immediate comment (later deleted) that stated setters shouldn’t have any side effects, and a SetProperty method would be a better choice.

Indeed, this seems to be Microsoft’s opinion as well. However, their properties often raise events, such as Resized when a form’s Width or Height property is set. OwenP also states “you shouldn’t let a property throw exceptions, properties shouldn’t have side effects, order shouldn’t matter, and properties should return relatively quickly.”

Yet Michael Stum states that exceptions should be thrown while validating data within a setter. If your setter doesn’t throw an exception, how could you effectively validate data, as so many of the answers to this question suggest?

What about when you need to raise an event, like nearly all of Microsoft’s Control’s do? Aren’t you then at the mercy of whomever subscribed to your event? If their handler performs a massive amount of information, or throws an error itself, what happens to your setter?

Finally, what about lazy loading within the getter? This too could violate the previous guidelines.

What is acceptable to place in a getter or setter, and what should be kept in only accessor methods?

Edit:

From another article in the MSDN:

The get and set methods are generally no different from other methods. They can perform any program logic, throw exceptions, be overridden, and be declared with any modifiers allowed by the programming language. Note, however, that properties can also be static. If a property is static, there are limitations on what the get and set methods can do. See your programming language reference for details.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    My view:

    1. If a setter or getter is expected to be expensive, don’t make it a property, make it a method.

    2. If setting a property triggers events due to changes, this is fine. How else would you allow listeners to be notified of changes? However, you may want to offer a BeginInit/EndInit pair to suppress events until all changes are made. Normally, it is the responsibility of the event handler to return promptly, but if you really can’t trust it to do so, then you may wish to signal the event in another thread.

    3. If setting a property throws exceptions on invalid values, it’s also fine. This is a reasonable way to signal the problem when the value is completely wrong. In other cases, you set a bunch of properties and then call a method that uses them to do something, such as make a connection. This would allow holding off validation and error-handling until the properties are used, so the properties would not need to throw anything.

    4. Accessing a property may have side-effects so long as they aren’t unexpected and don’t matter. This means a JIT instantiation in a getter is fine. Likewise, setting a dirty flag for the instance whenever a change is made is just fine, as it setting a related property, such as a different format for the same value.

    5. If it does something as opposed to just accessing a value, it should be a method. Method are verbs, so creating a connection would be done by the OpenConnection() method, not a Connection property. A Connection property would be used to retrieve the connection in use, or to bind the instance to another connection.

    edit – added 5, changed 2 and 3

    • 0