C#中如何正确处理空值转换为非可空类型的问题

我今年暑期担任.NET开发实习生，首次接触C#开发，在项目中频繁遇到警告：“Converting null literal or possible null value to non-nullable type”。以下是我编写的解析配置文件的代码示例：

private List<string> ParseConfiguration(IConfiguration configuration)
{
    // Attempt to parse configuration file and load connection data into a list.
    // Will be used to build out connection string later.
    try
    {
        List<string>? configurationInfo = configuration.GetSection("connection_info").Get<List<string>>();

        // Check to make sure configurationInfo is not null, as we have made
        // the list nullable earlier.
        if (configurationInfo == null)
        {
            throw new NoNullAllowedException();
        }

        return configurationInfo;
    }
    catch (Exception ex)
    {
        // Error re-thrown for Event Log. Outputting to console for
        // debugging purposes only.
        Console.WriteLine($"Error occurred attempting to parse configuration file.\n" +
            $"{ex.Message}");
        throw;
    }
}

我尝试将配置文件数据存入非可空类型List<string>，但配置可能为null导致警告。目前我通过给List<string>添加问号设为可空来消除警告，但认为这种方式不够安全，想了解行业专业人士的更优安全处理方案，是否仅需通过if语句检查对象状态？

你的核心需求是在确保空值安全的前提下消除Nullable警告，行业里有几种成熟的处理方式，结合你的场景逐一说明：

1. 保留空值检查，优化变量声明 #

你当前的if (configurationInfo == null)检查已经是安全的核心逻辑，可以简化变量声明——不需要显式声明为List<string>?，直接用null-forgiving运算符（!）配合检查即可：

private List<string> ParseConfiguration(IConfiguration configuration)
{
    try
    {
        // 用!标记编译器：我会处理空值，无需警告
        List<string> configurationInfo = configuration.GetSection("connection_info").Get<List<string>>()!;

        if (configurationInfo == null)
        {
            throw new InvalidOperationException("配置项connection_info未找到或格式错误");
        }

        return configurationInfo;
    }
    catch (Exception ex)
    {
        Console.WriteLine($"解析配置文件出错：\n{ex.Message}");
        throw;
    }
}

这里的!只是告诉编译器忽略空值警告，实际的空值检查逻辑依然保留，既消除了警告，又保证了运行时安全。另外建议把NoNullAllowedException换成更贴合场景的InvalidOperationException，语义更清晰。

2. 使用配置绑定的强类型方案（更推荐） #

.NET配置系统支持强类型绑定，这种方式从根源上减少空值风险，代码更简洁：

首先定义配置模型：

public class ConnectionConfig
{
    // 用[Required]标记必填项，配合绑定验证
    [Required]
    public List<string> ConnectionInfo { get; set; } = new();
}

然后修改解析方法：

private List<string> ParseConfiguration(IConfiguration configuration)
{
    try
    {
        var config = new ConnectionConfig();
        // 绑定并验证配置
        configuration.Bind(config);
        Validator.ValidateObject(config, new ValidationContext(config), validateAllProperties: true);

        return config.ConnectionInfo;
    }
    catch (ValidationException ex)
    {
        Console.WriteLine($"配置验证失败：\n{ex.Message}");
        throw;
    }
    catch (Exception ex)
    {
        Console.WriteLine($"解析配置文件出错：\n{ex.Message}");
        throw;
    }
}

这种方式的优势：

• 强类型定义，避免硬编码配置键名
• 可以通过数据注解（[Required]、[MinLength]等）做更细致的配置验证
• 模型初始化时给默认空列表，避免空值（但验证会确保配置项存在）

3. 使用空合并运算符提供默认值 #

如果业务上允许配置缺失时返回默认空列表，而非抛出异常，可以用空合并运算符（??）：

private List<string> ParseConfiguration(IConfiguration configuration)
{
    try
    {
        // 配置不存在时返回空列表，而非null
        return configuration.GetSection("connection_info").Get<List<string>>() ?? new List<string>();
    }
    catch (Exception ex)
    {
        Console.WriteLine($"解析配置文件出错：\n{ex.Message}");
        throw;
    }
}

这种方式适合非必填的配置项，无需额外空值检查，直接消除警告。

关于空值检查的必要性 #

回到你的疑问：仅通过if语句检查是否足够？
是的，只要你在使用变量前确保它不为null，这种检查就是安全的。编译器的警告只是提示你存在潜在空值风险，而你的检查已经覆盖了这个风险。结合null-forgiving运算符可以同时消除警告，这是行业里常用的做法。

内容的提问来源于stack exchange，提问作者James Clarke