Consider:
public class InitialStep2Sqlite : ScriptMigration
{
protected override string UpPath => "Sqlite2.Up.sql";
protected override string DownPath => "Sqlite2.Down.sql";
}
public abstract class ScriptMigration : Migration
{
protected virtual string UpPath {get;}
protected virtual string DownPath {get;}
protected override void Up(MigrationBuilder mb)
=> mb.RunSqlFile(UpPath);
protected override void Down(MigrationBuilder mb)
=> mb.RunSqlFile(DownPath);
}
which, compiled under nullable enable, says “[CS8618] Non-nullable property 'UpPath' must contain a non-null value when exiting constructor. Consider declaring the property as nullable.”
Changing the property's virtual
to abstact
removes the warning.
The lesson: If your non-null proof of a property depends crucially on the subclass making it non-null, then making the parent property abstract not virtual is the correct statement of intent.
Generally, if a parent Member depends on the subclass for correctness – if the parent can't provide a correct implementation itself – then, logically, its correctness requires it to be abstract not virtual.
One thought on “C# nullable refs and virtual vs abstract properties”