谁的错误是NullReferenceException？

Question

我目前正在研究一个通过属性公开内部List的类.列表应该并且可以修改.问题是,内部列表中的条目可以从类外部设置为null.

我的代码实际上是这样的:

class ClassWithList
{
    List<object> _list = new List<object>();

    // get accessor, which however returns the reference to the list,
    // therefore the list can be modified (this is intended)
    public List<object> Data
    {
        get
        {
            return _list;
        }
    }

    private void doSomeWorkWithTheList()
    {
        foreach(object obj in _list)
            // do some work with the objects in the list without checking for null.
    }
}

所以现在在doSomeWorkWithTheList()中,我总是可以检查当前列表条目是否为null,或者我可以假设使用此类的人没有将条目设置为null的好主意.

所以最后问题最终出现了:在这种情况下,谁的错误是NullReferenceException？是类开发人员没有检查null的所有错误(这通常会使代码 - 不仅在这个类中 - 更复杂)或者是这个类的用户的错误,因为将List条目设置为null doesn'真的有道理吗？除了在一些非常特殊的情况下,我倾向于通常不检查null的值.这是一种糟糕的风格或事实上的标准/标准吗？

我知道这可能没有最终答案,我只是缺少足够的经验来处理这样的事情,因此想知道其他开发人员对这些案例的看法,并希望听到关于检查null(或不是)的现实情况.

Answer 1

如果公开列表,则允许类的用户随意添加null引用.
如果您允许用户null随意添加引用,则您的类需要为null列表中的引用做好准备.

private void doSomeWorkWithTheList()
{
    foreach(object obj in _list)
        if (obj != null)
           // do some work with the object
}

如果你不喜欢这样,不要公开列表(应该公开为IList<T>btw),但是返回一个类似列表的集合,不允许null添加引用.

Answer 2

很抱歉直言不讳,但如果你的代码不合时宜,那就是你的错.如果您的代码的其余部分有此要求,那么如何封装列表,并公开一个null-checking add方法？也许你的类可以实现IList,并在内部存储你要处理的列表 - 然后在Add方法中,你只需抛出NullArgumentException或忽略null并继续...