.NET專案升級手記:可為空引用
c# 8引入了新特性:“可為空引用”(詳情),這個功能個人覺得挺好的,能夠非常明確的表現程式設計者的意圖,編譯器能夠進行檢查,盡最大可能減小NullReferenceException錯誤。
如果是新專案,那麼上手很簡單,一點點搭建起來,遇山開山,遇河渡河。但是對於我這種手頭上的專案大多都是以前建立的情況,就要稍微做那邊麼一點操作了。
要看完整說明,請檢視開頭的那個連結。
準備
首先評估一下幾個條件:
- 專案可以基於.NET CORE 3.0及以上編譯。如果不行,那麼就請直接右上角點×。
- 是不是大多數的變數都需要null引用?如果是的話,個人覺得不值得費勁了。
操作
以一個ASP.NET WEBAPI為例,專案修改前是能夠正常編譯無錯誤無警告的。
1. 啟用Nullable(可為空引用型別)
Nullable預設是不啟用的,需要做一些修改以啟用。有兩種方式:
- 修改csproj檔案,在ProperyGroup裡面新增
enable 項。
對於比較小型的專案,可以直接修改,這樣彈出來的警告或者錯誤會比較少,方便我們快速改正。
- 使用編譯器指令#nullable enable和#nullable restore進行修改。在程式碼段的開頭enable,結尾處restore。
對於中大型專案,直接使用第一種方式進行修改會導致大量的警告,很容易一團糟;可以通過編譯器指令對單檔案或者單類進行修改操作,一點一點地修改。
2. 修改程式碼
我的專案使用第一種方法的的情況下有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類使用建構函式保證不為空。
指定了default!的情況,ASP.NET CORE WEBAPI會內部自動標註[Required],遠端呼叫如果缺失引數,會提示bad request。
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不符合我們的設計,我們可以進行如下改造。
var baseDirectory = System.AppDomain.CurrentDomain.BaseDirectory;
if (baseDirectory == null) throw new ArgumentNullException("baseDirectory");
var xmlPath = Path.Combine(baseDirectory, System.AppDomain.CurrentDomain.FriendlyName + ".xml");
泛型類
public class ReturnData<T>
{
//整個型別會提示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約束。
public class ReturnData<T>
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<T>);
//提示dbset可能為null
var res = await dbset.FindAsync(value);
可以調整為下面的形式:
using ManageDataContext context = new ManageDataContext();
var props = contextType.GetProperty($"{namestring}s");
//判斷props可以解決問題。
if (props == null) throw new ArgumentNullException("Props");
var dbset = (props.GetValue(context) as DbSet<T>);
//判斷dbset可以解決問題。
if (dbset == null) throw new ArgumentNullException("dbset");
var res = await dbset.FindAsync(value);
注意,將as替換為強制轉換,並不能消除警告。
總結
最後消除了所有的警告,改造結束。
這個新的語言特性可以幫助我們發現一些潛在的bug點,幫助我們養成良好的程式設計習慣,也便於我們告訴其他人我們的設計意圖。
編譯器能幫我們做的工作,就沒必要自己再費勁做了,懶的不行,我得歇會兒