Validating data classes with nullable properties that should never be null

Question

When retreiving data with an api and saving it in a DTO, some values are nullable: null on initial class initialization but VS also warns you for this. For example, an employee:

public class EmployeeModel
{
    public Guid Id { get; set; }
    public int EmployeeNumber { get; set; }
    public string? FirstName { get; set; }
    public string? LastName { get; set; }
}

In practice, this might never happen because of database constraints obligating the user to enter all properties. But on creating the class and using it in the code, the FirstName might be null. How to deal with this? Two questions.

1) How to check if a class has no null values? Imagine the class has 10 string propeties and 2 int properties. To check if one of them is a null, I need 12 if statements. Which of course could be done in a separate method, see next question, but is still alot of code. And on adding a property, it must be manually added. And checking it outside a method is not enough without the NotNull as used in ArgumentNullException.

2) In case of null values, should ArgumentNullExceptions be used or a custom PropertyNullException? A property is not an argument, but a custom PropertyNullException is identical to ArgumentNullException part from the name. Simplified version:

public class PropertyNullException : Exception
{
    public string PropertyName { get; }

    public PropertyNullException(string propertyName)
        : base($"Property {propertyName}  is null.")
    {
        PropertyName = propertyName;
    }

    public PropertyNullException(string propertyName, Exception inner)
        : base($"Property {propertyName} is null.", inner)
    {
        PropertyName = propertyName;
    }

    public static void ThrowIfNull([NotNull] object? property, string propertyName)
    {
        if (property is null)
        {
            throw new PropertyNullException(propertyName);
        }
    }
}

Another option would be to, after a class creates the DTO's from the api, check all the properties for null/Guid.Empty/0 values? Or, of course, I'm doing something else wrong.

Answer 1

Assuming these DTOs are generated automatically, then you are stuck with whatever that tool gives you. This might be a good use case for class reflection. You could get meta data for all public properties, retrieve the current value of that property, and when you detect a null value, throw an exception.

Doing this has some benefits:

• Repeated if statements are replaced by a loop.

• No additional coding is necessary when adding or removing properties.

• This can be applied to any object, so no code repetition is necessary between classes.

• You could make this an extension method, so calling this utility method feels more object-oriented.

Class reflection has some drawbacks, though:

• It is very abstract and can be difficult to maintain if you are not familiar with this technique. I've found that many programmers consider this to be "advanced". They tend to prefer larger amounts of concrete code over smaller amounts of code which is more abstract.

• Reflected code runs slower. You get a penalty in runtime performance, however don't let this turn you away. Many times the difference in performance is negligible for the use case. Measure first.

  • Bear in mind that most ORMs and data mappers you already use are utilizing class reflection. Do you notice they run slow because of class reflection? Probably not.

• You might not find an appropriate built-in exception type to handle null values. Then again, this might not be a drawback, because you can easily create your own dedicated exception.

An illustration of this idea:

public static class DtoExtensions
{
    public static void EnsureNothingIsNull(this object instance)
    {
        var type = instance.GetType();

        // get property meta data
        // for each property, check for null
        // throw whatever exception you decide makes sense when null
    }
}

Calling this is as easy as:

var a = new FooDto();
var b = new BarDto();

a.EnsureNothingIsNull();
b.EnsureNothingIsNull();

This might be worthwhile if you have many DTOs that require this logic, which could offset the additional complexity introduced by class reflection. Prefer built-in exception types like Doc Brown mentioned. You don't need to get fancy. Exceptions are most useful to developers, so imagine you debugging this exception 6 months from now after you've forgotten the code you wrote. If a built-in type doesn't give you what you need, create your own exception type.

Answer 2

I made the experience that in reality, for most model classes and most string properties, it is rarely required to distinguish between null and the empty string.

Hence, first thing I would do here to use string instead of string? whenever possible. In C# version 8 and "nullable reference types" enabled, this can reduce the number of necessary tests for null heavily. Without nullable reference types, there is no difference between string and string?. You may try to work around the issue by some convention, or by other techniques like converting nulls to empty strings once-and-only during the construction process of your classes. The latter may also be an option if your DTOs are generated and you cannot simply choose string over string?.

This will already reduce the issue. It still leaves you with a few attributes for which you want to enforce not just "non-nullness", but "non-emptyness". For example, in your EmployeeModel, you may want to allow an empty FirstName, but not an empty LastName. Such constraints could be checked during a validation process, typically after construction (but YMMV, it often depends on the context where the validation is called best).

To your question which exception to throw from the validation: I would usually try to use the ones provided by the framework as long as they are sufficient. When you can foresee special requirements where you need to distinguish between standard and your own exceptions, then it is time to implement your own. Otherwise I would start with the most simple solution I can think of, which is reusing the existing ones.

Answer 3

public class EmployeeModel
{
    public Guid Id { get; set; } = Guid.NewGuid();
    public int? EmployeeNumber { get; set; } = null; //here I think you _need_ a nullable!
    public string FirstName { get; set; } = ""
    public string LastName { get; set; } = ""
}

Now, unless you set them to null deliberately (make sure your DB has NOT Null columns!), you are good.

Also, make liberal use of null coalescence ?? and null conditional ?. operators

Answer 4

In practice, this might never happen because of database constraints obligating the user to enter all properties

Well there's the problem right there. Presuming the DB is an integral part of a class' design. Never mind "nullable properties that should never be null." This is just a synecdoche for the broader problem of depending on the database to change an object to a valid state.

What class cares what the DB "thinks" anyway? The incoherent class does. Oh right, it's just a DTO - "just transporting to the DB, nothing to look at here!" As if the properties did not originate from an object with explicit requirements. It is an eternal trope of carelessness.