C# 8.0可空引用類型的使用注意記錄

更新時間：2019年04月07日 09:13:28 作者：自來喵的野

這篇文章主要給大家介紹了關于C# 8.0可空引用類型使用注意的相關資料，文中通過示例代碼介紹的非常詳細，對大家學習或者使用C#具有一定的參考學習價值，需要的朋友們下面來一起學習學習吧

前言

最近VS2019正式版發(fā)布了，裝下來順便試用了一下C#8.0，最大的看點應該就是可空引用類型了。不過C#8.0仍然處于Beta的狀態(tài)，而且試用時也遇到了幾個坑。

背景知識說明：

所謂的可空引用類型是指，一旦啟用了可空引用類型這個新特征，引用類型將默認被視為不可空，無法賦予null，除非手工將它設為可空引用類型。

實戰(zhàn)示例：

首先是新建一個C#的項目，在項目文件(.csproj)里加入兩行配置，目的是啟用“C#8.0語言”和“可空引用類型”：

<LangVersion>8.0</LangVersion>
<NullableContextOptions>enable</NullableContextOptions>

整個文件看起來是這樣的：

這樣就算是整個項目全局啟用了可空引用類型了。

注意：

在VS2019正式版中，使用

<NullableContextOptions>enable</NullableContextOptions>

而不是使用

<NullableReferenceTypes>true</NullableReferenceTypes>

后者在正式版中已經(jīng)失效了。

如果不希望全局啟用可空引用類型的話，可以在程序代碼中加入以下編譯指令：

#nullable enable

這樣可以在加入了該指令的文件中，單獨啟用可空引用類型。但是，極度不推薦這種做法。為什么呢？因為該指令僅僅在該文件中有效，不能跨文件生效，從而無法阻止null逃逸到使用了該指令的文件中，也就是說，用了也等于沒用。

一個很簡單的例子足以證明：

注意上面項目文件中并沒有全局啟用可空引用類型，而下面的Class1.cs中使用了編譯器指令來單獨啟用可空引用類型。

從運行結果可見，空引用仍然逃逸到使用了該指令的作用域中了。別說編譯錯誤，連編譯警告都沒有。完全達不到理想的效果。

因此，強烈建議在項目文件中全局啟用可空引用類型，而不是在某個源文件中單獨使用。

另外，還有一點要注意的是，即使啟用了可空引用類型后，默認情況下，即使對不可空引用賦予null，編譯器也只會生成編譯警告，而不是編譯錯誤。仍然是能夠編譯通過的。一個大項目中，編譯警告不可避免，甚至可能會很多，從而淹沒了“給不可空引用類型賦予空值”這種不起眼的警告。

因此，建議將特定的警告視為錯誤。警告編號為8600、8625、8618、8604，或者將所有警告視為錯誤。具體是在項目文件中加入以下設置（見圖一）：

<WarningsAsErrors>8600 8625 8618 8604</WarningsAsErrors>

或者在項目編輯器中設置也可以：

這是我自己測試得出的結果，可能還有其它潛在的相關警告編號我沒有測試出來。如果有誰知道的話，告訴我一下，謝謝。

做好這些配置之后，可以看到引用類型默認都不能賦予空值了：

這時候普通的引用類型的變量和參數(shù)都不能設為null了。

這樣可以防止空值擴散開來，引起惱人的空引用異常。

但是，這里有個坑需要注意?。。?！

struct里不適用可空引用的規(guī)則??！

這種情況下直接運行，仍然會拋出空引用異常?。?！C#8.0仍未能完全封堵住空引用的逃逸。

其實我還是比較贊同用不可空引用類型的方案的，而不是可空引用類型的方案。畢竟我想要的，只不過是一個不可空的斷言，只是想利用不可空引用來劃分安全邊界，從而防止空值的擴散。簡單來說就是想將變量和參數(shù)明確聲明為不可空引用類型。因為歷史和現(xiàn)實的原因，大量的庫都還沒能全面使用可空引用類型。這種情況下，只有我使用可空引用類型，是不靠譜的。無法劃分安全邊界。

然而C#選擇了可空引用類型的方案，而且還不是強制啟用，而且默認只是警告。。跟沒有一樣。。。

比方說，我使用了一個第三方庫項目，而空值的來源是正好是該庫項目的，而我對這個庫并沒有源代碼或者修改權限。這時候就無法阻止空值逃逸到我的項目中了。

還是之前的代碼，只是稍微做一下修改。新增了一個庫項目ClassLibrary1，這個庫并沒有使用可空引用類型。