這篇文章將介紹將C# 7類庫升級到C# 8（支持可空引用類型）的一個案例。本案例中使用的項目Tortuga Anchor由一組MVVM風格的基類、反射代碼和各種實用程序函數組成。之所以選擇這個項目，是因爲它很小，並且同時包含了慣用和不常用的C#模式。
關鍵要點
- 爲每個項目啓用可空引用類型。
- 使用泛型時，可能需要禁用可空引用類型。
- 可以通過在本地變量中緩存屬性來修復警告。
- 公開方法仍然需要進行Null參數檢查。
- .NET Framework和.NET Core的反序列化方式是不一樣的。
這篇文章將介紹將C# 7類庫升級到C# 8（支持可空引用類型）的一個案例。本案例中使用的項目Tortuga Anchor由一組MVVM風格的基類、反射代碼和各種實用程序函數組成。之所以選擇這個項目，是因爲它很小，並且同時包含了慣用和不常用的C#模式。
項目設置
目前，可空引用類型僅適用於.NET Standard和.NET Core項目。在Visual Studio 2019發佈時，應該也支持.NET Framework。
在項目文件中，添加或修改以下配置：
</PropertyGroup>
<LangVersion>8.0</LangVersion>
<NullableContextOptions>enable</NullableContextOptions>
</PropertyGroup>
在保存文件後，應該會看到可空性錯誤。如果沒有看到，請嘗試構建項目。
指示一個類型可以爲空
在接口方法GetPreviousValue中，返回類型可以爲空。爲了顯式地說明這一點，可以在object後面跟上可空類型修飾符（?）。
object? GetPreviousValue(string propertyName);
使用這個類型修飾符註解變量、參數和返回類型，就可以解決項目中的很多編譯器錯誤。
延遲加載屬性
如果一個屬性的求值成本非常高，可以使用延遲加載模式。在使用這個模式時，如果私有字段爲空，表示尚未生成字段的值。
C# 8可以很好地處理這種情況。在不改變代碼的情況下，它能夠正確地分析代碼，以確定getter的結果將始終非空，儘管返回的變量可以爲空。
string? m_CSharpFullName;
public string CSharpFullName
{
get
{
if (m_CSharpFullName == null)
{
var result = new StringBuilder(m_TypeInfo.ToString().Length);
BuildCSharpFullName(m_TypeInfo.AsType(), null, result);
m_CSharpFullName = result.ToString();
}
return m_CSharpFullName;
}
}
需要注意的是，這裏存在潛在的競態條件。理論上，另一個線程可以將m_CSharpFullName的值設置回null，而編譯器無法檢測到。因此，在處理多線程代碼時要特別小心。
一個變量的可空性由另一個變量決定
在下一個代碼示例中，當且僅當m_ItemPropertyChanged不爲空時，m_ListeningToItemEvents才爲true。編譯器無法知道這個規則。如果是這種情況，你可以將（!）附加到變量（在本例中爲m_ItemPropertyChanged）後面，表示它在這個時間點不會爲空。
if (m_ListeningToItemEvents)
{
if (item is INotifyPropertyChangedWeak)
((INotifyPropertyChangedWeak)item).AddHandler(m_ItemPropertyChanged!);
else if (item is INotifyPropertyChanged)
((INotifyPropertyChanged)item).PropertyChanged += OnItemPropertyChanged;
}
使用顯式強制轉換糾正誤報
在下一個示例中，編譯器錯誤地報告了m_Base的可空性。Values與IEnumerable
readonly Dictionary<ValueTuple<TKey1, TKey2>, TValue> m_Base;
IEnumerable<TValue> IReadOnlyDictionary<ValueTuple<TKey1, TKey2>, TValue>.Values
{
get { return (IEnumerable<TValue>)m_Base.Values; }
}
請注意編譯器將該行標記爲具有冗餘強制轉換。這是正常的編譯器消息，而不是警告，但希望在發佈時能夠得到更正。
使用臨時變量或條件強制轉換糾正誤報
在下一個示例中，編譯器指出CancelEdit所在行存在一個錯誤。雖然前面的if語句證明item.Value不爲空，但編譯器不相信下次讀取item.Value時它仍然是不爲空。
foreach (var item in m_CheckpointValues)
{
if (item.Value is IEditableObject)
((IEditableObject)item.Value).CancelEdit();
}
我們可以將item.Value保存在一個臨時變量中。
foreach (var item in m_CheckpointValues)
{
object? value = item.Value;
if (value is IEditableObject)
((IEditableObject)value).CancelEdit();
}
對於這種情況，我們可以通過使用條件轉換（as操作符）後面跟上一個條件方法調用（?.操作符）進一步簡化它。
foreach (var item in m_CheckpointValues)
{
(item.Value as IEditableObject)?.CancelEdit();
}
泛型和可空類型
如果你經常使用泛型，可能會遇到一個有問題的可空類型。看一下這個delegate：
public delegate void ValueChanged<in T>(T oldValue, T newValue);
這個delegate的預期設計是oldValue和newValue都可以爲空。所以，你會認爲加幾個問號就可以解決問題。但是，這樣做會返回下面這樣的錯誤消息：
Error CS8627 可空類型參數必須是值類型或非可空的引用類型。可以考慮添加“class”、“struct”或類型約束。
如果你需要同時支持值類型和引用類型，那麼這個問題就沒那麼容易解決。由於你無法在類型約束中表達“or”，你需要一個用於類的delegate和一個用於結構體的delegate。
public delegate void ValueChanged<in T>(T? oldValue, T? newValue) where T : class;
public delegate void ValueChanged<T>(T? oldValue, T? newValue) where T : struct;
但是，這樣不起作用，因爲兩個delegate具有相同的名稱。你可以給它們起不一樣的名稱，但你必須複製使用它們的代碼。
所幸的是，C#有一個轉義值。你可以使用#nullable指令恢復成C #7的語義，這樣就可以達到預期的效果。
#nullable disable
public delegate void ValueChanged<in T>(T oldValue, T newValue);
#nullable enable
這種方法並非沒有缺陷。禁用可空引用可能是個好東西，但也可能什麼都不是。你無法用它來讓oldValue變成可空或讓newValue變成不可空。
構造函數、反序列化器和初始化方法
對於下一個示例，你必須知道序列化器的一些技巧。有一個鮮爲人知的函數用來繞過一個叫作FormatterServices.GetUninitializedObject的類構造函數。一些序列化器（如DataContractSerializer）使用它來提高性能。
如果你總是要運行構造函數中的邏輯，應該怎麼辦？這個時候需要用到OnDeserializing屬性。這個屬性充當在GetUninitializedObject之後調用的代理構造函數。
爲了減少冗餘和出錯的可能性，開發人員通常會使用常見的初始化方法，如下面的代碼所示。
protected AbstractModelBase()
{
Initialize();
}
[OnDeserializing]
void _ModelBase_OnDeserializing(StreamingContext context)
{
Initialize();
}
void Initialize()
{
m_PropertyChangedEventManager = new PropertyChangedEventManager(this);
m_Errors = new ErrorsDictionary();
}
這對null檢查器來說是個問題。由於構造函數中沒有顯式地設置上述兩個變量，因此它會把它們標記爲未初始化。這意味着需要進行一些複製粘貼工作來移除這個錯誤。
還有一個風險，那就是忘記包含OnDeserializing方法。由於null檢查器不理解OnDeserializing方法，因此如果出現意外空值就無法提醒你。
大多數開發人員發現這種行爲令人困惑。因此，在.NET Core中，DataContractSerializer將調用構造函數。但這意味着如果你的目標是.NET Standard，則需要使用.NET Framework和.NET Core測試反序列化代碼，以理解不同的行爲。
可空參數和CallerMemberName
這個庫大量使用了CallerMemberName模式。根據它使用的屬性命名，基本思想是在方法的末尾添加一個可選參數。編譯器將看到CallerMemberName，並隱式地爲該參數提供一個值。
public override bool IsDefined([CallerMemberName] string propertyName = null)
從理論上講，propertyNameparameter可以顯式設置爲null，但人們普遍認爲不應該這樣做，因爲這樣可能會發生意外的錯誤。
將這行代碼轉換爲C# 8時，可能會想要將參數標記爲可空。這樣具有誤導性，因爲這個方法實際上並不是爲處理空值而設計的。相反，你應該用空字符串替換null。
public override bool IsDefined([CallerMemberName] string propertyName = "")
還需要空參數檢查嗎？
如果要構建公共庫（即NuGet），那麼是的，所有公開方法仍然需要檢查空參數。使用庫的應用程序可能不一定會使用可空引用類型。事實上，他們甚至可能根本不使用C# 8。
如果你的所有應用程序代碼都使用了可空引用類型，那麼答案仍然是“可能是”。雖然從理論上講，你不會看到任何意外的空值，但由於動態代碼、反射或誤用（!）操作符，它們仍然可能會出現。
結論
在一個只有不到60個類文件的項目中，其中24個類文件需要更改。但沒有一個是特別重要的，整個過程花了不到一個小時。總之，這是一個無痛的過程，大多數事情都像預期的那樣。我希望大多數項目都能從這個特性中獲益，並且在C# 8發佈後就應該使用這個特性。
關於作者
Jonathan Allen在90年代後期開始爲一家醫療診所做MIS項目，逐步將Access和Excel應用到企業解決方案中。在花了五年時間爲金融行業編寫自動化交易系統之後，他成爲了多個項目的顧問，其中包括機器人倉庫的UI、癌症研究軟件的中間層，以及一家大型房地產保險公司對大數據的需求。在他的空閒時間，他喜歡學習和寫作與16世紀武術相關的東西。
英文原文：https://www.infoq.com/articles/csharp-nullable-reference-case-study