I have a DTO which is populated by reading from a DynamoDB table. Say it looks like this currently:
public class Item
{
public string Id { get; set; } // PK so technically cannot be null
public string Name { get; set; } // validation to prevent nulls but this doesn't stop database hacks
public string Description { get; set; } // can be null
}
Is there any best practice developing for dealing with this? I'd rather avoid a non-parameterless constructor since that plays badly with the ORM in the Dynamo SDK (as well as others).
It seems strange to me to write public string Id { get; set; } = "";
because this will never happen since Id
is a PK and can never be null. What use would ""
be even if it did somehow anyway?
So any best practice on this?
string?
to say they can be null even though some never should be.Id
and Name
with ""
because they should never be null and this shows the intent even though ""
would never be used.Please note: this is about C#8 nullable reference types If you don't know what they are best not answer.
Although using nullable reference types can introduce its own set of problems, I still think it's beneficial because it helps you find potential bugs and allows you to better express your intent in the code. For new projects, I would recommend you enable the feature and do your best to write code without warnings.
NullReferenceException. Nullable reference types includes three features that help you avoid these exceptions, including the ability to explicitly mark a reference type as nullable: Improved static flow analysis that determines if a variable may be null before dereferencing it.
Nullable reference types are a new feature in C# 8.0. They allow you to spot places where you're unintentionally dereferencing a null value (or not checking it.) You may have seen these types of checks being performed before C# 8.0 in ReSharper's Value and Nullability Analysis checks.
Nullable reference types aren't new class types, but rather annotations on existing reference types. The compiler uses those annotations to help you find potential null reference errors in your code. There's no runtime difference between a non-nullable reference type and a nullable reference type.
As an option, you can use the default
literal in combination with the null forgiving operator
public class Item
{
public string Id { get; set; } = default!;
public string Name { get; set; } = default!;
public string Description { get; set; } = default!;
}
Since your DTO is populated from DynamoDB, you can use MaybeNull/NotNull
postcondition attributes to control the nullability
MaybeNull
A non-nullable return value may be null.NotNull
A nullable return value will never be null.But these attributes only affect nullable analysis for the callers of members that are annotated with them. Typically, you apply these attributes to method returns, properties and indexers getters.
So, you can consider all of your properties non-nullable ones and decorate them with MaybeNull
attribute, indicating them return possible null
value
public class Item
{
public string Id { get; set; } = "";
[MaybeNull] public string Name { get; set; } = default!;
[MaybeNull] public string Description { get; set; } = default!;
}
The following example shows the usage of updated Item
class. As you can see, second line doesn't show warning, but third does
var item = new Item();
string id = item.Id;
string name = item.Name; //warning CS8600: Converting null literal or possible null value to non-nullable type.
Or you can make all properties a nullable ones and use NoNull
to indicate the return value can't be null
(Id
for example)
public class Item
{
[NotNull] public string? Id { get; set; }
public string? Name { get; set; }
public string? Description { get; set; }
}
The warning will be the same with previous example.
There is also AllowNull/DisallowNull
precondition attributes for input parameters, properties and indexers setters, working on the similar way.
AllowNull
A non-nullable input argument may be null.DisallowNull
A nullable input argument should never be null.I don't think that it will help you, since your class is populated from database, but you can use them to control the nullability of properties setters, like this for the first option
[MaybeNull, AllowNull] public string Description { get; set; }
And for second one
[NotNull, DisallowNull] public string? Id { get; set; }
Some helpful details and examples of post/preconditions can be found in this devblog article
Update: As of .NET 5.0.4 (SDK 5.0.201), which shipped on March 9th, 2021, the below approach will now yield a
CS8616
warning. Given this, the approach of setting the value todefault
with the null-forgiving operator (i.e.,default!
), as discussed at the top of @Pavel-Anikhouski’s answer, is now your best bet.
The textbook answer in this scenario is to use a string?
for your Id
property, but also decorate it with the [NotNull]
attribute:
public class Item
{
[NotNull] public string? Id { get; set; }
public string Name { get; set; }
public string? Description { get; set; }
}
Reference: According to the documentation, the
[NotNull]
attribute "specifies that an output is not null even if the corresponding type allows it."
So, what exactly is going on here?
string?
return type prevents the compiler from warning you that the property is uninitialized during construction and will thus default to null
.[NotNull]
attribute prevents a warning when assigning the property to a non-nullable variable or attempting to dereference it since you are informing the compiler's static flow analysis that, in practice, this property will never be null
.Warning: As with all cases involving C#'s nullability context, there's nothing technically stopping you from still returning a
null
value here and thus, potentially, introducing some downstream exceptions; i.e., there's no out-of-the-box runtime validation. All C# ever provides is a compiler warning. When you introduce[NotNull]
you are effectively overriding that warning by giving it a hint about your business logic. As such, when you annotate a property with[NotNull]
, you are taking responsibility for your commitment that "this will never happen sinceId
is a PK and can never be null."
In order to help you maintain that commitment, you may additionally wish to annotate the property with the [DisallowNull]
attribute:
public class Item
{
[NotNull, DisallowNull] public string? Id { get; set; }
public string Name { get; set; }
public string? Description { get; set; }
}
Reference: According to the documentation, the
[DisallowNull]
attribute "specifies thatnull
is disallowed as an input even if the corresponding type allows it."
This may not be relevant in your case since the values are being assigned via the database, but the [DisallowNull]
attribute will give you a warning if you ever attempt to assign a null
(able) value to Id
, even though the return type otherwise allows for it to be null. In that regard, Id
would act exactly like a string
as far as C#'s static flow analysis is concerned, while also allowing the value to remain uninitialized between the construction of the object and the population of the property.
Note: As others have mentioned, you can also achieve a virtually identical outcome by assigning the
Id
a default value of eitherdefault!
ornull!
. This is, admittedly, somewhat of a stylistic preference. I prefer to use the nullability annotations as they're more explicit and provide granular control, whereas it's easy to abuse the!
as a way of shutting up the compiler. Explicitly initializing a property with a value also nags at me if I know I'm never going to use that value—even if it is the default.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With