Wednesday 10 July 2013

What is the difference between a field and a property in C#?



Fields and properties look the same, but they are not. Properties are methods and as such there are certain things that are not supported for properties, and some things that may happen with properties but never in the case of fields.

Here's a list of differences:

  • Fields may be used as input to out/ref arguments. Properties may not.

  • A field will always yield the same result when called multiple times (if we leave out issues with multiple threads). A property such as DateTime.Now is not always equal to itself.

  • Properties may throw exceptions - fields will never do that.

  • Properties may have side effects or take a really long time to execute. Fields have no side effects and will always be as fast as can be expected for the given type.

  • Properties support different accessibility - fields do not (but fields can be made readonly)

  • When using reflection the properties and fields are treated as different MemberTypes so are located differently (GetFields vs GetProperties for example)

  • The JIT Compiler may treat property access very differently to field access. It may however compile down to identical native code but the scope for difference is there.

  • An important difference is that interfaces can have properties but not fields

  • Properties may run for a very long time, have side effects, and may even throw exceptions. Fields are fast, with no side effects, and will never throw exceptions. Due to side effects a property may return a different value for each call (as may be the case for DateTime.Now, i.e. DateTime.Now is not always equal to DateTime.Now). Fields always return the same value.

  • Fields may be used for out / ref parameters, properties may not. Properties support additional logic – this could be used to implement lazy loading among other things.

  • Using Properties, you can throw an event, when the value of the property is changed (aka. PropertyChangedEvent) or before the value is changed to support cancelation.

  • public class Person {
     private string _name;
     public event EventHandler NameChanging;    
     public event EventHandler NameChanged;
     public string Name{
      get
      {
         return _name;
      }
      set
      {
         OnNameChanging();
         _name = value;
         OnNameChanged();
      }
     }
     private void OnNameChanging(){
       EventHandler localEvent = NameChanging;
       if (localEvent != null) {
         localEvent(this,EventArgs.Empty);
       }
     }
     private void OnNameChanged(){
       EventHandler localEvent = NameChanged;
       if (localEvent != null) {
         localEvent(this,EventArgs.Empty);
       }
     }
    }

  • In the background a property is compiled into methods. So a Name property is compiled into get_Name() and set_Name(string value). You can see this if you study the compiled code. So there is a (very) small performance overhead when using them. Normally you will always use a Property if you expose a field to the outside, and you will often use it internally if you need to do validation of the value.

The remote server returned an error: (500) Internal Server Error

When the remote server returns an error, then it means that the remote server noticed something bad. When the error is 500, that means it's an internal error, meaning internal to the service - the service threw an exception that was not caught.

The remote server don't return the correct HTML, so it throw errors.

Check Windows event viewer logs you might get more information on the reason of the 500 error.