原文：Nullable Reference Types In C# 8
作者：.NET Core Tutorials
譯者：Lamond Lu

現狀

可空引用型別？

自從我開始學習.NET, 引用型別一直就是可空的。然而初級程式設計師通常會告訴你值型別不可空，引用型別可空。

事實上，在.NET中有一種語法可以表明一個值型別是否可空。

int? nullableInt1 = null;
Nullable<int> nullableInt2 = null;
int nullableInt3 = null; //編譯錯誤

並且這種語法並不只適用於原始型別，它也適用於struct

Tips: Struct本身就是值型別

struct MyStruct
{
 
}
        
static void Main(string[] args)
{
    MyStruct? mystruct1 = null;
    MyStruct myStruct2 = null;
}

但是現在我們希望在編譯以下程式碼時，編譯器能給出錯誤或者警告

class MyClass
{
 
}
        
static void Main(string[] args)
{
    MyClass myClass = null; 
}

為什麼？

這裡我們第一個問題就是，為什麼需要讓編譯器給出錯誤或者警告？

我們接下來已一段簡單的程式碼為例。

class MyClass
{
    public void SayHello()
    {
        Console.WriteLine("Hello");
    }
}
        
static void Main(string[] args)
{
    var myClass = new MyClass(); 
    myClass.SayHello();
}

這個程式碼是某個功能的最初版本，看起來非常的簡單，並且會執行的很好。

現在我們想象一下，一段之間之後，另外一個程式設計師加入了專案，將程式修改如下

class MyClass
{
    public void SayHello()
    {
        Console.WriteLine("Hello");
    }
}
        
static void Main(string[] args)
{
    var myClass = new MyClass();
 
    ...
    
    if (true)  
    {
        myClass = null;
    }
    
    ...
 
    if(myClass == null)
    {
        ...
    }
    
    ...

    myClass.SayHello();
}
 

這樣的程式碼看起來很傻，但是現實情況中確實會發生，有人會將myClass設定為null來滿足他們正在處理的功能。它深藏在程式中，甚至可以通過單元測試，所有的功能看起來都執行良好。

但是在某個特定的時間點, 特定的條件下，程式會丟擲一個NullReferenceException空引用異常, 這時候我們才會發現我們缺少了空引用判斷，然後新增一定的防護。

class MyClass
{
    public void SayHello()
    {
        Console.WriteLine("Hello");
    }
}
        
static void Main(string[] args)
{
    var myClass = new MyClass();
 
    ...
    
    if (true)  
    {
        myClass = null;
    }
    
    ...
 
    if(myClass == null)
    {
        ...
    }
    
    ...

    if(myClass != null)
    {
         myClass.SayHello();   
    }
}

那麼如何避免其他程式設計師，或者未來的自己，陷入這種空引用的陷阱呢？

啟用可空引用型別

如上所述，這裡我們首先需要使用C＃8的Nullable Reference Types功能。 完成後，只需要在專案的csproj檔案中新增一行：

<NullableReferenceTypes>true</NullableReferenceTypes>

就可以了。

編譯器產生警告

一旦我們啟用了該功能，讓我們看一段簡單的程式碼來說明它是如何工作的。

class MyClass
{
    public void SayHello()
    {
        Console.WriteLine("Hello");
    }
}
 
static void Main(string[] args)
{
    MyClass myClass = null;
    myClass.SayHello();
}

如果編譯以上程式碼的話，我們會得到2個警告。這裡我使用了加粗字型，是因為我們得到的只是警告，不是編譯錯誤。你的程式依然可以編譯和啟動。

第一個警告是我們嘗試將null分配給未明確設定為允許空值的變數。

Converting null literal or possible null value to non-nullable type.

第二個警告是當我們嘗試實際使用非可空型別時，編譯器認為它將為null。

Possible dereference of a null reference.

所以這兩個警告都不會阻止我們的應用程式執行，但它會警告我們我們可能遇到麻煩。

下面讓我們修改程式碼，讓我們的引用型別變數可空

C# 8中可用引用型別的定義於可空值型別一樣，即在宣告時，型別名的後面加？號

static void Main(string[] args)
{
    MyClass? myClass = null;
    myClass.SayHello();
}

這裡有趣的是，修改完程式碼後，編譯專案，你依然會收到Possible dereference的警告。為了消除掉這個警告，你可以新增空引用檢查。

static void Main(string[] args)
{
    MyClass? myClass = null;
    if (myClass != null)
    {
        myClass.SayHello();
    }
}

至此，所有的警告都消失了。

編譯器警告的限制

在我們實際編碼過程中，引用型別可以在方法，類，甚至程式集中傳遞。因此丟擲警告時，它並不是萬無一失的。例如，我們有如下程式碼：

class MyClass
{
    public Random Random = new Random();
}
 
 
static void Main(string[] args)
{
    MyClass myClass = new MyClass();
    SomeMethod(myClass);
    var next = myClass.Random.Next(1, 10);
}
 
static void SomeMethod(MyClass myClass)
{
    myClass.Random = null;
}

這裡編譯器只會警告我們在分配一個null值給一個沒有明確指定可空的變數。但是我們不會得到Possible dereference的警告。這裡我們可以推斷，一旦將物件傳遞到方法之外，無論在那裡發生什麼（如設定null），我們都不會被警告。但是如果我們在相同的程式碼/方法塊中如此明確地分配null，然後嘗試使用它，那麼編譯器將嘗試給我們一個幫助。

為了與上述程式碼比較，以下程式碼確實會收到2條警告

static void Main(string[] args)
{
    MyClass myClass = new MyClass();
    if (new Random().Next(1, 10) > 5)
    {
        myClass = null;
    }
 
    myClass.SayHello();
}

啟用可空引用型別的嚴格模式

如果你希望用錯誤替換警告，你可以升級整個檢查到嚴格模式。這裡你只需要在專案的csproj檔案中新增一行：

<TreatWarningsAsErrors>true</TreatWarningsAsErrors>

注意： 這會將所有警告視為錯誤，而不僅僅是關於空引用問題的警告。但這意味著如果有警告被丟擲，你的專案將不再編譯！