.NET項目更新手記：可為空引用

.NET項目更新手記：可為空引用

c# 8引入了新特性：“可為空引用”（詳情），這個功能個人覺得挺好的，能夠非常明确的表現程式設計者的意圖，編譯器能夠進行檢查，盡最大可能減小NullReferenceException錯誤。

如果是新項目，那麼上手很簡單，一點點搭建起來，遇山開山，遇河渡河。但是對于我這種手頭上的項目大多都是以前建立的情況，就要稍微做那邊麼一點操作了。

要看完整說明，請檢視開頭的那個連結。

準備

首先評估一下幾個條件：

項目可以基于.NET CORE 3.0及以上編譯。如果不行，那麼就請直接右上角點×。

是不是大多數的變量都需要null引用？如果是的話，個人覺得不值得費勁了。

操作

以一個ASP.NET WEBAPI為例，項目修改前是能夠正常編譯無錯誤無警告的。

1. 啟用Nullable（可為空引用類型）

   Nullable預設是不啟用的，需要做一些修改以啟用。有兩種方式：

修改csproj檔案，在ProperyGroup裡面添加enable項。

對于比較小型的項目，可以直接修改，這樣彈出來的警告或者錯誤會比較少，友善我們快速改正。

使用編譯器指令#nullable enable和#nullable restore進行修改。在代碼段的開頭enable，結尾處restore。

對于中大型項目，直接使用第一種方式進行修改會導緻大量的警告，很容易一團糟；可以通過編譯器指令對單檔案或者單類進行修改操作，一點一點地修改。

1. 修改代碼

   我的項目使用第一種方法的的情況下有24個警告（編譯後有67個），也不知道算多還是算少。

實體類

[DataContract]

[Table("recordinfo")]
public class RecordInfo : InfoBase
{
    /// <summary>
    /// 記錄ID
    /// </summary>
    [DataMember]
    [Key]
    public string RecordNum { get; set; }
    /// <summary>
    /// 車輛RFID号碼
    /// </summary>
    [DataMember]
    public string CarID { get; set; }           

RecordNum為主鍵，通過EF進行映射，結果也不會為null，是以聲明應該保持原樣即可。CarID不是主鍵，有可能是null，是以應當顯式聲明為string?，表示可以為空，删除警告。

編譯器檢查，RecordNum沒有被初始化，我們的設計意圖告訴編譯器了，但是代碼還沒有保證這個不能為空，是以需要修改代碼保證RecordNum不為空。

這裡使用null包容運算符（！）來進行操作，提示編譯器這個位置實際上不會為null。

//string的default為null，通過增加！告訴編譯器，這塊初始化的時候實際上是不為空的。

public string RecordNum { get; set; } = default!;

null包容運算符并不能確定不是null，如果可以使用代碼確定不為null，那麼使用代碼會是更優選擇。考慮如下代碼：

//我經常使用String.IsNullOrWhiteSpace來進行檢查，空文本對我的業務沒有意義，是以适用。

public string RecordNum { get; set; } = "";

特别提示：

可為空引用類型檢查是編譯器的行為，它可以提供編譯時檢查，但是不提供運作時檢查，如果使用外部代碼調用，那麼是否為空都可以進行指派。

很明顯，上面代碼運作時也很難保證不是null，我們可以再改進一下。

public string RecordNum

{

get => recordNum;
set => recordNum = value ?? "";           

}

private string recordNum = "";

官方推薦對POCO類使用構造函數保證不為空。

DataContext類

DataContext也是類似的，主要是DbSet對象的引用問題。

來自.NET Class Library

//BaseDirectory的傳回是string?類型的

var baseDirectory = System.AppDomain.CurrentDomain.BaseDirectory;

//Path.Combine()不接受string?，提示錯誤。

var xmlPath = Path.Combine(baseDirectory, System.AppDomain.CurrentDomain.FriendlyName + ".xml");

這是一個潛在的bug點，對于以上代碼，很顯然BaseDirectory的傳回為null不符合我們的設計，我們可以進行如下改造。

if (baseDirectory == null) throw new ArgumentNullException("baseDirectory");

泛型類

public class ReturnData

//整個類型會提示Data未能初始化，ErrorMsg未能初始化。
public ReturnData(){ }
public ReturnData(T data) => Data = data;
public ReturnData(string error) => ErrorMsg = error;
/// <summary>
/// 頁面資料
/// </summary>
public T Data { get; set; }
public string ErrorMsg { get; set; }           

設計意圖：Data與ErrorMsg不同時為空，也不同時有值。

基于設計，可以做如下修改。注意添加了class限制。

where T: class           

public ReturnData(){ }
public ReturnData(T data) => Data = data;
public ReturnData(string error) => ErrorMsg = error;
/// <summary>
/// 頁面資料
/// </summary>
public T? Data { get; set; }
public string? ErrorMsg { get; set; }           

其他例子

using ManageDataContext context = new ManageDataContext();

var props = contextType.GetProperty($"{namestring}s");

//props提示有可能為null

var dbset = (props.GetValue(context) as DbSet);

//提示dbset可能為null

var res = await dbset.FindAsync(value);

可以調整為下面的形式：

//判斷props可以解決問題。

if (props == null) throw new ArgumentNullException("Props");

//判斷dbset可以解決問題。

if (dbset == null) throw new ArgumentNullException("dbset");

注意，将as替換為強制轉換，并不能消除警告。

總結

最後消除了所有的警告，改造結束。

這個新的語言特性可以幫助我們發現一些潛在的bug點，幫助我們養成良好的程式設計習慣，也便于我們告訴其他人我們的設計意圖。

編譯器能幫我們做的工作，就沒必要自己再費勁做了，懶的不行，我得歇會兒。

原文位址

https://www.cnblogs.com/podolski/p/12692888.html