Clarifying how set and get work in c#

Question

I have seen that get/set properties can be used in two different ways:

Without any logic:

public string PublicString { get; set; }

With logic, passing the value to backing field.

private string backingString;
public string PublicString 
{ 
    Get
    {
        Return backingString;
    } 
    Set
    {
        If (value != “”)
        {
            backingString = value;
        }
    }                            
}

Questions:

if you want to perform logic, do you have a backing property or is it possible to do PublicString = value?
if you want to return an error when you failed to set the field, what would be the best practice for doing this?

Thanks

possible duplicate of [c# { get; set; } shortcut](http://stackoverflow.com/questions/16752577/c-sharp-get-set-shortcut) — H H, Nov 23 '13 at 16:09

Markus · Accepted Answer · 2013-11-23T16:50:20.777

The short form above automatically creates a backing field for the property and a getter and setter that only return or set the value of the backing field.
If you decide to implement the getter and setter manually, you do not need to have a backing field. In fact, you can implement whichever logic you require (e.g. deriving the value from another field). However, it is common practice for property getter and setters to be lightweight as this matches the expectations of the caller. If you need a lot of logic I the property, methods are a better approach and should be named so that the communicate their purpose to the caller.
If you want to store the value somewhere, a backing field is a common approach (unless you store the value in another place). It won't work to assign the value to the property itself as you show in your example (PublicString = value) because this calls the setter again and this ends in an endless loop.
If you fail to set the value, you can communicate this to the caller by throwing an exception. However, as properties tend to be lightweight, it should not the standard scenario that properties throw exceptions. Again, if setting the property is so complicated or the signature of a property does not allow for a caller to understand how to use the property (so that the use ends in an exception), methods might be a preferred approach.

I'm a bit confused about your comment "If you decide to implement the getter and setter manually, you do not need to have a backing field." - How would you implment logic and set the value without a backing feild? Or is it as Ondrej Janacek describes. — Gregory William Bryant, Nov 23 '13 at 17:04
What I want to say is that properties and backing fields are basically unrelated. A property can exist without a backing field, e.g. if you want to return a fixed value from your property, e.g. a name that never changes. However, the standard for properties is that they are used to publish the value of an internal field (the backing field). To support that "80% case", there is the short form. — Markus, Nov 23 '13 at 17:24
Yeah, that's true for getters, however there are setter what's mainly in question. You obviously can have setter without a backing field, but then you can't set that exact property and you have to set anything else or do nothing with a received value. — Ondrej Janacek, Nov 23 '13 at 18:04

score 3 · Answer 2 · answered Nov 23 '13 at 16:38

Microsoft has published the following guidelines for Property Design:

http://msdn.microsoft.com/en-us/library/ms229006.aspx

Regarding property getter/setter exceptions:

√ DO preserve the previous value if a property setter throws an exception.

X AVOID throwing exceptions from property getters. Property getters should be simple operations and should not have any preconditions. If a getter can throw an exception, it should probably be redesigned to be a method. Notice that this rule does not apply to indexers, where we do expect exceptions as a result of validating the arguments.

score 2 · Answer 3 · answered Nov 23 '13 at 16:29

If you wish to have a logic in setter, you need a backup field. Otherwise, if you would try

public int Number
{            
    set
    {
        Number = value;
    }
}

it would cause a recursion when setting the property. As for the second question, throwing an exception is fine in case your co-workers or users of that library are used to fact that properties sometimes substitute behaviour of methods. Personally, I don't do that. If setting of a property can fail I typically make a method which sets the property instead and mark it with

/// <exception cref=""></exception>

Clarifying how set and get work in c#

3 Answers3