Bird
Raised Fist0
C Sharp (C#)programming~3 mins

Why Property validation logic in C Sharp (C#)? - Purpose & Use Cases

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
The Big Idea

What if your program could stop mistakes the moment they happen, without extra effort?

The Scenario

Imagine you have a class with many properties, like a user profile. You want to make sure the age is never negative and the email looks correct. Without validation, you have to check these rules everywhere you use the properties.

The Problem

Manually checking property values all over your code is slow and easy to forget. It leads to bugs when invalid data sneaks in. Fixing errors later wastes time and frustrates users.

The Solution

Property validation logic lets you put checks right inside the property itself. This means invalid values are stopped immediately, keeping your data clean and your code simpler.

Before vs After
Before
user.Age = age;
if (user.Age < 0) throw new Exception("Age cannot be negative");
After
private int age;
public int Age {
  get => age;
  set {
    if (value < 0) throw new Exception("Age cannot be negative");
    age = value;
  }
}
What It Enables

This makes your programs safer and easier to maintain by catching errors right where data is set.

Real Life Example

Think of an online form where users enter their birthdate. Property validation ensures the date is valid before saving, preventing wrong or harmful data from entering the system.

Key Takeaways

Manual checks scattered in code cause bugs and slow development.

Property validation centralizes rules, stopping bad data early.

It leads to cleaner, safer, and easier-to-maintain programs.

Practice

(1/5)
1. What is the main purpose of adding validation logic inside a property setter in C#?
easy
A. To check and control the value before saving it to the field
B. To make the property read-only
C. To speed up the program execution
D. To automatically generate a default value

Solution

  1. Step 1: Understand property setters

    Property setters allow you to assign values to private fields through a controlled interface.
  2. Step 2: Role of validation logic

    Validation logic inside the setter checks if the value is valid before saving it, preventing invalid data.
  3. Final Answer:

    To check and control the value before saving it to the field -> Option A
  4. Quick Check:

    Validation in setter = control value before save [OK]
Hint: Validation logic in setter controls data before saving [OK]
Common Mistakes:
  • Thinking validation makes property read-only
  • Assuming validation speeds up code
  • Confusing validation with default value assignment
2. Which of the following is the correct syntax to throw an exception inside a property setter when the value is invalid?
easy
A. set { if (value < 0) throw new Exception("Invalid value"); field = value; }
B. set { if (value < 0) return; field = value; }
C. set { if (value < 0) Console.WriteLine("Invalid"); field = value; }
D. set { if (value < 0) break; field = value; }

Solution

  1. Step 1: Identify correct exception throwing syntax

    Throwing an exception uses the keyword 'throw' followed by 'new Exception(message)'.
  2. Step 2: Check each option

    set { if (value < 0) throw new Exception("Invalid value"); field = value; } correctly throws an exception if value is less than zero. Others use invalid statements like return, Console.WriteLine, or break inside setter.
  3. Final Answer:

    set { if (value < 0) throw new Exception("Invalid value"); field = value; } -> Option A
  4. Quick Check:

    Throw exception = throw new Exception(...) [OK]
Hint: Use 'throw new Exception' to stop invalid values [OK]
Common Mistakes:
  • Using 'return' instead of 'throw' in setter
  • Trying to use 'break' inside setter
  • Only printing error without stopping assignment
3. Consider this C# class snippet:
class Person {
  private int age;
  public int Age {
    get => age;
    set {
      if (value < 0) throw new ArgumentException("Age cannot be negative");
      age = value;
    }
  }
}

What happens if you run this code?
var p = new Person();
p.Age = -5;
medium
A. The age is set to -5 without error
B. An ArgumentException is thrown with message 'Age cannot be negative'
C. The program crashes with a NullReferenceException
D. The setter ignores the negative value and leaves age unchanged

Solution

  1. Step 1: Analyze setter validation

    The setter checks if value is less than 0 and throws ArgumentException if true.
  2. Step 2: Apply to given code

    Setting Age to -5 triggers the exception because -5 < 0.
  3. Final Answer:

    An ArgumentException is thrown with message 'Age cannot be negative' -> Option B
  4. Quick Check:

    Negative age triggers ArgumentException [OK]
Hint: Setter throws exception on invalid input [OK]
Common Mistakes:
  • Assuming negative value is accepted
  • Confusing exception type thrown
  • Thinking setter silently ignores invalid values
4. Identify the error in this property setter code:
private string name;
public string Name {
  get { return name; }
  set {
    if (value == null || value == "")
      throw new ArgumentException("Name cannot be empty");
    name = value;
  }
}
medium
A. The setter does not assign the value to the field
B. The setter should use 'value.Equals("")' instead of 'value == ""'
C. The setter does not check for whitespace-only strings
D. The setter should not throw exceptions in property setters

Solution

  1. Step 1: Review validation logic

    The setter checks if value is null or empty string but does not check if value is whitespace only.
  2. Step 2: Understand missing validation

    Strings like " " (spaces) pass the check but are usually invalid for a name.
  3. Final Answer:

    The setter does not check for whitespace-only strings -> Option C
  4. Quick Check:

    Missing whitespace check in setter validation [OK]
Hint: Check for whitespace with string.IsNullOrWhiteSpace [OK]
Common Mistakes:
  • Thinking '==' is wrong for string comparison here
  • Believing exceptions should never be thrown in setters
  • Forgetting to assign value to field
5. You want to create a property Score that only accepts values between 0 and 100 inclusive. If the value is outside this range, it should throw an ArgumentOutOfRangeException. Which of these implementations correctly applies this validation?
hard
A. private int score; public int Score { get => score; set { if (value < 0 && value > 100) throw new ArgumentOutOfRangeException("Score must be 0-100"); score = value; } }
B. private int score; public int Score { get => score; set { if (value <= 0 && value >= 100) throw new ArgumentOutOfRangeException("Score must be 0-100"); score = value; } }
C. private int score; public int Score { get => score; set { if (value > 0 || value < 100) throw new ArgumentOutOfRangeException("Score must be 0-100"); score = value; } }
D. private int score; public int Score { get => score; set { if (value < 0 || value > 100) throw new ArgumentOutOfRangeException("Score must be 0-100"); score = value; } }

Solution

  1. Step 1: Understand the range condition

    The value must be between 0 and 100 inclusive, so invalid values are less than 0 or greater than 100.
  2. Step 2: Analyze each condition

    private int score; public int Score { get => score; set { if (value < 0 || value > 100) throw new ArgumentOutOfRangeException("Score must be 0-100"); score = value; } } uses 'value < 0 || value > 100' which correctly checks invalid values. Options A, B, and D use incorrect logical operators or conditions.
  3. Final Answer:

    private int score; public int Score { get => score; set { if (value < 0 || value > 100) throw new ArgumentOutOfRangeException("Score must be 0-100"); score = value; } } -> Option D
  4. Quick Check:

    Use '||' for out-of-range checks [OK]
Hint: Use 'if (value < min || value > max)' for range validation [OK]
Common Mistakes:
  • Using '&&' instead of '||' in range checks
  • Reversing comparison operators
  • Throwing wrong exception type