返回List<int>的方法遇错误时的返回值与异常处理方案咨询

这是个很常见的设计决策问题，得结合你的程序上下文来选最合适的方案，我给你拆解几个常用的思路：

方案1：抛出自定义异常（推荐在调用者需要明确感知错误的场景） #

如果获取数据失败是不能被忽略的严重问题（比如数据库连不上、权限不足），那抛出自定义异常是最优解。这样调用者必须主动处理异常，不会把“获取失败”和“本来就没数据”搞混——毕竟有时候空列表是正常业务结果，而失败是异常情况。

修改后的代码示例：

// 先定义自定义异常，方便调用方针对性捕获
public class DataRetrievalException : Exception
{
    public DataRetrievalException(string message, Exception innerException) 
        : base(message, innerException) { }
}

private List<int> GetData() 
{
    try
    {
        // 假设ProcessThatGetsData内部会抛出异常
        return ProcessThatGetsData();
    }
    catch (Exception ex)
    {
        // 包装原始异常，保留错误栈同时提供更清晰的业务错误信息
        throw new DataRetrievalException("获取整数列表数据失败", ex);
    }
}

调用方就可以针对性捕获这个异常，比如给用户弹提示、记录详细日志。

方案2：返回空列表（适合无数据和获取失败可以同等处理的场景） #

如果你的业务逻辑里，“没数据”和“获取失败”对调用者来说没区别（比如UI上都是显示空列表，不需要额外提示），那返回空列表是最安全的——调用者不用额外判空，直接遍历就行，不会触发NullReferenceException。

代码示例：

private List<int> GetData() 
{
    try
    {
        return ProcessThatGetsData();
    }
    catch (Exception ex)
    {
        // 一定要记录错误日志！不然出问题根本不知道原因
        Logger.LogError("获取数据时发生错误", ex);
        return new List<int>();
    }
}

方案3：返回null（不推荐，除非有明确业务约定） #

返回null的话，调用者必须记得每次都判空，不然很容易踩空指针的坑。除非你的团队有严格约定（比如返回null表示获取失败，空列表表示真的没有数据），否则尽量别用这个方案——它会给后续维护埋下隐患。

• 要让调用者必须处理错误（比如要给用户反馈）：选自定义异常
• 错误可以静默处理，调用者只关心结果：选返回空列表
• 尽量避免返回null，除非有特殊业务需求

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