实际上这很重要吗?还是只是开发人员个人偏好的问题?
最好返回一个空的集合。这样当有人像这样调用函数时:
foreach(var i in items)
{
}
它不会在它们身上抛出空引用异常。
严格来说,你可以争论空的与null
的含义,但实际上很多人(我自己有时也是)会忘记防御性编程,不会在使用对象之前检查它是否为null。这会导致他人假设会发生什么,从而减少错误和愤怒的用户。
如果返回空集合而不是null,你的迭代代码将变得更加容易。
然而,区分空集合和没有数据的集合可能很重要,因此这取决于实际类型的语义。
如果发生错误,应该抛出异常。如果没有数据可返回,则返回一个空集合。当开发人员请求列表中的项目并且恰好没有要返回时,通常不应该出现NullReferenceException
。
我能看到这两种方式的可行性。最终,数组或集合会占用更多的空间,但从“安全”角度来看,如果将结果在未来的foreach/迭代中使用,则结果将跳过代码块并不会出现null对象异常。
嗯,“null”和“empty”有两个不同的含义。一个空集合有效地意味着“这里没有任何东西”,并且可能是有效的。如果基于一个空集合,你如何知道是否出了问题?
虽然对于调用方法来说更安全,但这并不比返回null更好。良好的实践规定,在对对象进行操作之前应该检查null。反正这很便宜。
如果确实出了问题,为什么不能抛出异常呢?
这真的取决于开发者的个人喜好。
通常我会返回一个空列表,这样方法的接收者就不需要检查 null 并避免任何可能的 NullReferenceException
。
因此,任何期望列表的人都可以遍历列表,即使列表为空(这将是一个非常快速的 for-each 循环)。
如果您处于内存耗尽的环境中,则可以优化为返回 null 值。但是,这意味着每个使用相关方法的人都需要检查 null,并且无法解决可能的内存泄漏问题。
虽然我认为这主要取决于开发者的个人喜好,但返回一个空集合可能是更好的方法。
假设你有一个包含集合成员的对象。
public class Customer {
private IList<Order> _orders;
public Customer() {
_orders = new List<Order>();
}
public IList<Order> Orders {
get {
return _orders;
}
}
}
通常情况下,人们更喜欢将此成员作为只读属性,以便其客户的订单不会因没有明显原因而丢失。因此,返回null
不是一个选项。与null引用相比,您可能更喜欢使用空集合。因此,在类构造函数中实例化集合是更好的方法。
最重要的是,在使用数据绑定时,如果返回null集合引用,则可能会出现奇怪的行为,最好使用空集合。
另一个例子是,当迭代集合时,例如:
foreach (Order o in c.Orders) {
// Do something here...
}
这个 foreach
循环在集合为空时不会被执行,而无需您先检查它是否为 null 引用。它简化了代码并减少了复杂性。
这取决于您所工作的场景。